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ABSTRACT 


The  data  base  machine  called  RAP  (Relational  Associative  Processor) 
is  an  associative-array  processor  designed  to  support  data  base  management.  An 
experimental  version  of  it  is  being  implemented  at  the  University  of  Toronto. 

In  this  paper  we  briefly  summarize  the  architecture  of  RAP  and  then  describe  its 
instruction  set  in  an  assembler  language  format.  The  RAP  instruction  set  is  a 
high  level  algebraic  query  language  implemented  directly  in  hardware.  Although 
RAP  can  be  used  for  implementing  several  data  models,  in  this  paper  we  concentrate 
on  its  ability  to  support  relational  data  bases.  A  description  of  the  instructions 
is  given  and  templates  are  constructed  for  doing  relational  algebraic  operations. 
These  templates  equivalently  prove  the  relational  completeness  of  the  language. 
Examples  that  demonstrate  RAP's  programming  power  are  also  included. 
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1.  INTRODUCTION 

The  Relational  Associative  Processor  (RAP)  is  a  cellular  associative 
array  processor  for  supporting  data  base  management  systems.  Each  cell 
of  the  processor  is  composed  of  a  circulating  sequential  memory  and 
a  microprocessor  designed  specifically  for  the  needs  of  data  base 
management.  RAP  serves  as  a  back-end  or  peripheral  processor.  The 
front-end  is  a  general  purpose  computer  for  user  interfacing,  RAP  program 
compilation,  and  RAP  system  monitoring. 

The  microprocessor  of  a  cell  is  primarily  designed  for  performing 
the  primitives  for  data  format  sensing,  associative  searching,  and 
data  manipulation.  These  primitives  are  implemented  as  hardwired  machine 
instructions,  which  are  also  instructions  of  the  RAP  language.  The 
RAP  language  can  be  used  to  support  all  the  operations  of  the  relational 
algebra.  Also,  many  desired  data  processing  operations  such  as  the  "in- 
place”  or  direct  computing  of  statistical  functions  and  in-place  updates 
can  be  performed  with  the  RAP  instruction  set.  We  assume  that  the  reader' 
is  familiar  with  the  relational  concepts  and  terminology  [5,10]. 

In  this  paper,  we  provide  a  complete  list  of  templates  in  RAP 
language  for  each  of  the  relational  algebra  operations.  They  are  necessary 
in  showing  the  relational  completeness  of  RAP  [7,10].  An  observation 
of  these  templates  also  show  the  high  level  features  of  the  RAP  language. 

The  uniqueness  of  the  RAP  language  over  other  relational  algebra  and/or 
calculus  oriented  languages  is  that  RAP  instructions  are  directly  executable 
machine  instructions  of  an  associative-array  processor. 

The  high  level  features  of  the  RAP  language  makes  it  easier  to 
interface  with  a  more  English-like  user  query  language.  Further, 
such  an  implementation  would  be  straightforward  by  the  virtue  of  RAP 
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being  also  a  machine  language.  This  potentially  saves  a  great  amount 
of  software  compared  to  possible  relational  implementations  with 
conventional  computers. 

1.1  Basic  RAP  Architecture 

RAP  is  composed  of  parallel  organization  of  cells,  a  controller, 
and  a  set  function  (statistical  arithmetic)  unit.  Figure  1  shows  the 
overall  RAP  organization.  A  cell  consists  of  a  circulating  sequential 
memory  (i.e.,  a  track  of  a  disc  or  drum,  CCD,  bubble  memory,  etc.) 
and  a  microprocessor.  This  processor  is  designed  to  perform  data  search, 
manipulation,  and  other  relational  algebra  operations  as  well  as  limited 
numeric  computations.  Each  cell  has  a  unique  integer  identifier. 

The  set  function  unit  is  used  to  combine  cell  results  computed  for  set 
functions  so  that  an  overall  result  can  be  obtained.  The  controller 
is  responsible  for  overall  coordination  and  sends  initiation  control 
sequences  to  the  cells,  controls  the  set  function  unit,  and  executes 
decision  commands  and  other  RAP  primitives  that  it  can  execute  directly. 
It  also  provides  the  external  interface  and  controls  data  transfers 
between  RAP  and  the  supporting  external  processor  (i.e.,  the  front-end). 

1.2  Cell  organization 

The  functional  organization  of  a  cell  can  be  grouped  under  two  major 
units.  They  are  the  Information  Search  and  Manipulation  Unit  (ISMU) 
and  the  Arithmetic  Logic  Unit  (ALU).  Cell  memory  contents  are  circulated 
through  the  cell  logic  via  a  buffer  whose  overall  length  controls  the 
maximum  length  of  a  RAP  tuple  (see  next  section).  The  length  of  this 
buffer  is  an  optional  hardware  parameter. 


Figure  1.  Overview  of  RAP  architecture 


-3- 


1.2.1  Data  structure  and  storage  format 

The  physical  data  structure  chosen  for  RAP  is  referred  to  as  a 
RAP  relation.  A  RAP  relation  is  Codd's  [5]  normalized  relation  except 
that  the  maximum  degree  is  restricted  by  a  hardware  parameter  and  also 
several  additional  one-bit  domains  (called  the  mark  domains)  are  attached 
to  each  relation.  Furthermore,  duplicate  tuples  do  not  affect  operation 
of  RAP.  A  tuple  of  the  resulting  relation  is  referred  to  as  a  RAP  tuple. 
Figure  2  shows  the  structure  of  a  RAP  relation. 

According  to  the  RAP  storage  format  (or  sometimes  referred  to  as 
the  track  format)  a  RAP  relation  is  stored  in  a  cell  simply  by  laying 
tuples  one  after  another  and  labelling  the  beginning  of  each  cell  by  a 
header  information  (i.e.,  physical  schema)  consisting  of  relation  and 
domain  names.  Figure  3  shows  the  RAP  storage  format.  According  to  this 
format,  tuples  and  items  within  tuples  can  be  in  discrete  variable 
lengths.  For  specific  values  of  the  hardware-dependent  RAP  parameters 
that  are  implemented  and/or  modelled  presently,  the  reader  should  refer 
to  appendix-2.  A  relation  can  occupy  more  than  one  cell  and  each  cell 
is  an  independent  entity  in  both  hardware  (i.e.,  cellular  organization) 
and  data  structure  (i.e.,  by  repeating  the  schema  in  each  cell  and  not 
splitting  tuples  between  cells).  A  cell  cannot  contain  more  than  one 
relation.  Cells  of  a  relation  need  not  be  contiguous. 

A  cell  may  contain  data  and/or  garbage.  The  memory  allocation 
scheme  of  the  RAP  hardware  packs  data  (tuples)  towards  the  beginning 
of  the  memory  leaving  a  pool  of  empty  tuples  (garbage)  towards  the  end. 
Whenever  an  insertion  is  directed  new  coming  tuples  are  added  to  the  end 
of  the  packed  data. 
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As  can  be  seen  from  figure  4  there  is  an  additional  fifth  (or 
nineth  in  the  extended  option)  bit  in  front  of  each  tuple  (i.e.,  in 
addition  to  the  mark  domains)  and  referred  to  as  the  delete  flag. 

The  tuple  which  is  deleted  by  a  delete  instruction  is  first  delete- 
flagged,  then  the  garbage  collection  hardware,  operating  in  the  back¬ 
ground  without  user  initiation,  physically  deletes  the  tuple. 

1.2.2  Information  Search  and  Manipulation  Unit  (ISMU) 

This  functional  unit  of  the  cell  microprocessor  is  responsible  for 
almost  all  activities  in  a  cell  except  the  arithmetic  operations.  In 
general,  this  unit  is  responsible  for  inter-cell  communication,  data 
transfers  for  mapping  operations  and  user  outputs,  executing  the 
relational  commands  sent  from  the  controller,  and  control  of  the  ALU. 

The  commands  sent  from  the  controller  require  a  search  criterion  to 
be  evaluated  on  the  buffer  memory  contents  before  any  operation  is 
performed  on  it.  This  is  part  of  the  tasks  of  the  ISMU. 

1.2.3  Arithmetic  Logic  Unit  (ALU) 

This  unit  performs  arithmetic  operations  on  the  data  items  provided 
by  the  ISMU  and  updates  the  resultant  item  with  the  newly  computed  value. 
It  also  computes  set  functions  of  the  SUM,  COUNT,  MAX,  and  MIN  over  its 
cell  memory  and  stores  them  in  the  cell  accumulator  so  that  they  can  be 
transferred  to  the  set  function  unit.  The  set  function  unit  computes 
the  overall  result  by  combining  the  cell  results. 

1.3  Controller 

The  controller  is  responsible  for  the  overall  coordination  of 
the  cell  processors.  It  loads  the  search  criteria  units  of  ISMU's, 
asserts  opcode  and  mode  lines,  senses  end  of  an  operation,  and  repeats 
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the  cycle  for  the  next  primitive.  The  control  memory  of  the  controller 
initiates  retrieval  of  the  instruction  parameter  data  from  the  controller 
storage  and  sends  them  onto  the  cell  busses  during  storage  gap  intervals. 
The  controller  also  executes  some  of  the  RAP  instructions  directly  in 
itself.  Other  operations  such  as  providing  interface  and  data  transfers 
between  RAP  and  the  supporting  processor  and  error  checking  procedures 
which  are  common  tasks  in  most  I/O  controllers  are  also  functions  of 
the  RAP  controller. 

1.4  RAP  instruction  set 

The  RAP  system  has  a  machine  oriented  yet  high  level  and  complete 
instruction  set  for  manipulating  its  data  base.  These  instructions 
are  implemented  in  hardware.  The  instruction  set  can  be  divided  into 
the  following  major  data  base  management  operations. 

a)  retrieval, 

b)  update, 

c)  set  function, 

d)  insertion  and  deletion 

e)  data  definition 

f)  decision  and  transfer. 

Each  command  corresponds  to  an  "assembler"  language  instruction  for  the 
RAP  machine.  Cells  execute  a  given  instruction  simultaneously.  A  data 
base  query  can  be  compiled  into  one  or  more  assembler  instructions.  Most 
instructions  are  executed  within  one  circulation  of  the  entire  RAP  memory 
contents.  Since  RAP  is  highly  parallel  and  has  an  associative  memory, 
the  response  time  is  usually  independent  of  data  base  size  or  content 
but  does  depend  somewhat  on  query  complexity  (i.e.,  the  number  and  type 
of  instructions  of  a  query). 
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2.  RAP  LANGUAGE 

In  this  section  a  machine  independent  explanation  of  the  RAP 
language  will  be  presented  so  that  it  can  be  studied  as  a  "relational 
language".  Machine  oriented  discussion  of  the  language  can  be  found 
elsewhere  [1,2,3].  The  emphasis  will  be  on  the  relational  algebra 
operations  for  which  the  RAP  templates  are  constructed.  Also,  query 
examples  are  included  in  the  appendix-3  to  clarify  the  RAP  programming  concepts. 

2.1  Basic  relational  operations 

The  RAP  instruction  set  is  designed  to  construct  the  basic 
operations  necessary  to  support  data  bases  and  at  the  same  time  remain 
feasible  for  hardware  implementation.  The  basic  operations  are  essentially 
the  operations  of  the  relational  algebra  [6,7,10]  augmented  with 
the  essential  data  base  management  operations  as  listed  in  section  1.4. 

The  operations  of  the  relational  algebra  are; 

a)  union 

b)  intersection 

c)  difference 

d)  projection 

e)  cartesian  product 

f)  restriction 

g)  implicit  join 

h)  division 

Before  explaining  these  operations  and  giving  RAP  templates  for  them, 
we  first  present  the  basic  structure  of  a  RAP  instruction  followed  by 
the  description  of  each  individual  instruction. 
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2.2  Instruction  format 

The  general  format  of  a  RAP  instruction  is: 

<LABEL>  <0PC0DE>  [<SPECI FICATI0N> : <QUALI FICATI0N>]  [<PARAMETERS>] 

The  label  is  an  optional  symbolic  instruction  address.  The  opcode 
specifies  the  operation. 

A  specification  has  the  following  format: 

R  (D1 ,  D2,. . . ,Ds) 

where  R  is  a  relation  name  and  D1 ,  D2,...,Ds  is  an  optional  domain 
name  list.  The  index  s  is  the  hardware  limit  on  the  number  of  domain 
names  that  can  be  included  for  any  speci fi cation--see  appendix-2.  A 
qualification  is  a  conjunctive  or  disjunctive  Boolean  expression  of 
conditions  on  the  values  of  domains  of  a  relation  including  the  mark 
domains  or  the  address  or  identifier  of  a  cell. 

Before  going  into  further  details  it  would  be  proper  to  re-examine 
the  RAP  relational  structure  at  this  point.  As  stated  earlier  in  the 
general  description  of  RAP,  each  relation  has  extra  one-bit  domains  in 
addition  to  the  usual  domains  of  a  relation.  These  domains  are  referred 
to  as  the  mark  domains,  or  mark  bits.  These  mark  bits  are  used  to 
enhance  the  selection  power  of  the  associative  search.  A  query  criterion 
can  combine  the  set  or  reset  (i.e.,  true  or  false)  status  of  combinations 
of  these  mark  bits  in  the  Boolean  qualification  of  an  instruction.  These 
mark  bits  serve  as  selectors  or  resemble  user  work  areas  in  query  processing. 
They  are  used  in  doing  mappings  between  or  within  relations,  subsetting 
a  relation,  and  combining  results  of  individual  operations. 

A  qualification  in  the  RAP  instruction  format  can  take  the 


following  forms: 


-8- 


a)  Null  --  implies  every  tuple  of  the  relation  is  eligible 

b)  Q1  A  Q2  A... A  QK  denoting  simple  conjunctions 

c)  Q1  I  Q2  I-..  I  QK  denoting  simple  disjunctions 

where  K  has  the  hardware  limit  k  --  see  appendix-2.  A  Q  can  be  one 
of  the  following: 

a)  <D>  <C0MPARAT0R>  <0PERAND> 
where 

1)  D  is  a  domain  name 

2)  COMPARATOR  (or  COMP)  is  one  of  =,  f,  <,  <,  >,  > 

3)  OPERAND  is  one  of: 

a  RAP  register 

integer 

literal 

a  program  variable 

Comparisons  are  done  algebraically.  This  implies  a  reverse  order  in 
alphabetic  comparisons  since  the  2's  complement  notation  for  negative 
numbers  is  used. 

b)  MKED(T)  denoting  any  combination  of  TRUE  mark  bits 

c)  UNMKED(T)  denoting  any  combination  (i.e.,  implied  conjunction) 
of  FALSE  mark  bits.  Permutations  are  considered  identical. 

d)  CELL(I),  where  I  is  the  integer  address  of  a  cell. 

When  needed  a-1 ,  b,  and  c  can  be  qualified  by  relation  name  (i.e.,  R.MKED(T)). 
2.3  Description  of  RAP  instructions 

2.3.1  Retrieval  commands 

2. 3. 1.1  MARK 

<Label>  MARK(<T>)  [<R> : <QUALIFICATION>] 

Mark  sets  the  T  mark  bitCs)  of  the  qualified  tuples  of  a  relation. 
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In  other  words,  combination  of  mark  domains,  as  specified  by  T,  of 
the  qualified  (i.e.,  those  that  meet  the  associative  addressing 
qualification)  tuples  take  the  value  true  after  the  execution  of  this 
instruction.  It  leaves  the  values  of  T  untouched  in  tuples  where  the 
qualification  is  false. 

2. 3. 1.2  RESET 

This  instruction  does  exactly  the  opposite  of  mark.  It  resets 
(or  gives  value  false)  to  those  mark  domains,  as  specified  by  T,  of 
the  eligible  (i.e.,  qualified)  tuples  of  a  relation.  It  leaves  the 
values  of  T  in  tuples  untouched  where  the  qualification  is  false. 

2. 3. 1.3  READ 

<Label>  READ  [<R>(D1 ,D2 , . . . ,Ds) :<QUALIFICATION>][WORKAREA] 

Read  transfers  data  from  the  eligible  tuples  of  a  relation  to 
the  supporting  processor's  storage  whose  address  is  specified  by  the 
workarea.  If  a  specification  list  is  present  only  those  item  values 
are  read  out,  otherwise  entire  eligible  tuple  is  transferred. 

If  the  qualification  expression  consists  only  of  MKED(T)  term, 

T  being  a  single  mark  domain,  then  reading  starts  immediately  resetting 
T  bits  as  tuples  are  read,  otherwise  an  automatic  marking  operation  is 
performed  first  to  mark  the  eligible  tuples  on  the  tl  mark  domain. 

In  subsequent  revolutions,  those  marked  tuples  are  read-out  and  tl 
marks  reset. 

The  reading  operation  over  the  entire  RAP  is  performed  according 
to  a  special  read-out  scheme  [2,9,11].  This  scheme  uses  a  special 
multiplexing  arrangement  which  can  interleave  the  output  of  eligible 
tuples  from  different  cells  to  reduce  total  reading  time  to  a  number  of 
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revolutions  much  less  than  the  number  of  cells  occupied  by  the  relation. 

Extra  revolutions  occur  only  if  there  exists  more  eligible  tuples  at 
a  given  tuple  position  between  the  cells.  According  to  the  analysis 
performed  on  read-out  response  [9,11],  the  number  of  extra  revolutions  in 
environments  where  mostly  very  selective  data  are  required  (e.g.,  on-line 
query  systems)  is  determined  to  be  negligible. 

2 . 3 . 1 . 4  READ_REG 

<Label>  READ_REG  [<REG>  ,<REG>  , . .  ,<REG>] 

This  instruction  transfers  contents  of  the  specified  RAP  registers 
to  the  supporting  processor. 

2. 3. 1.5  CROSS_MARK 

<Label>  CR0SS_MARK(<T1>)  [<R1>;<D1><C0MP><R2>.<D2>][<R2>-MKED(<T2>)] 

This  instruction  involves  operations  between  two  relations  called 
source  (R2)  and  target  (Rl).  It  works  like  a  repetetive  mark  instruction 
on  the  target  relation  with  the  exception  that  qualification  for  each 
marking  is  obtained  from  the  source  relation  domain  values.  That  is, 
in  order  to  mark  a  target  relation  tuples  the  domains  D1  and  D2  respectively 
of  target  and  source  relations  must  have  values  that  satisfy  a  COMP  comparison 
between  them.  Target  tuples  are  Tl-marked  and  source  tuples  participating 
in  the  operation  are  those  that  are  T2-marked.  The  operation  is  iterative 
by  nature  (however,  this  iteration  is  built  into  hardware)  since  it 
continues  until  all  T2-marked  source  items  are  compared  with  the  target 
relation  and  since  in  each  pass  target  cells  can  receive  only  k  arguments 
each  (i.e.,  maximum  number  of  terms  in  a  RAP  instruction's  disjunctive 
Boolean  qualification).  During  the  process  some  tuples  in  the  target 
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relation  may  qualify  for  redundant  marking.  An  algorithm  that  eliminates 
the  passing  of  duplicate  source  values  will  be  given  later.  Since  RAP 
is  associative,  searching  and  marking  on  the  target  relation  is  executed 
in  the  fastest  possible  time.  The  number  of  eligible  source  items  is 
the  only  determining  factor  for  the  overall  duration  of  the  operation. 

2. 3. 1.6  CRS_COND_MARK 

<Label>  CRS_C0ND_MARK(<T1  >[<Tr >] )  [<R1>:<D1><C0MP><R2>-<D2>] 
[<R2>-MKED(<T2>)] 

This  command  works  very  similar  to  the  cross_mark  command. 

The  differences  are  the  following: 

a)  Target  relation  starts  as  Tl-marked. 

b)  There  is  no  actual  marking,  that  is,  those  target  tuples  that 
qualify  are  left  Tl-marked  and  the  others  are  temporarily  reset. 

No  action  is  final  before  the  end  of  the  operation  since  cross 
marking  is  disjunctive.  For  this  reason  the  initial  T1  domain 
values  are  saved  in  the  T1 '  mark  domain. 

c)  The  criterion  on  each  pass  is  that  target  tuples  must  be  T1  or 
T1 '  marked  and  that  the  comparison  between  domains  D1  and  D2 
must  satisfy  the  COMP  condition.  Therefore,  the  criterion  is 
conjunctive  on  each  tuple,  but  the  overall  operation  is  disjunctive 
on  the  target  relation. 

d)  At  the  end  of  the  operation,  contents  of  Tl'  domain  are  erased. 

The  semantics  of  this  instruction  can  be  understood  better  after 


seeing  the  relational  templates  given  in  section  3. 
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2. 3. 1.7  GET_FIRST_MARK 

<Ldbel>  GET_FIRST_MARK(<T1>)  [<R>(<D1 > , . . .  ,<Dr>) :<Da><COMP><Db>] 
[MKED(<T2>)] 

The  get_first_mark  instruction  also  works  similar  to  the  cross jnark 
instruction  with  the  following  differences: 

a)  Source  and  target  relations  are  the  same,  that  is,  the  operation 
of  this  instruction  involves  a  single  relation. 

b)  In  each  pass  only  one  value  is  taken  from  the  Db  domain  of  the 
source  and  applied  as  a  criterion  to  the  entire  target  relation 
to  be  compared  according  to  COMP  with  the  Da  domain.  Da  and  Db 
can  be  the  same  or  different  domains  of  the  relation. 

c)  The  source  tuple  is  sequentially  the  first  T2-marked  tuple  of 
the  relation.  It  is  T2-reset  after  its  domain  value  is  passed 
as  an  argument  and  T1 -marking  on  the  relation  is  completed. 

d)  Apart  from  marking,  in  each  pass  optionally  up  to  r  (see  appendix-2) 
items  of  the  source  tuple  can  be  saved  in  the  RAP  controller 
registers  to  be  used  in  fi'rther  operations.  These  registers 

are  called  REGC_1 ,  REGC_2,  and  REGC_3. 

The  use  of  this  instruction  is  quite  important  in  accomplishing 
complete  power  of  the  relational  algebra.  Its  typical  usage  requires  a 
program  iteration  and  therefore,  a  RAP  program  with  an  explicit  loop 
using  RAP  branch  commands  must  be  constructed. 

2. 3. 1.8  GET_FIRST 

<Label>  GET_FIRST  [<R>(<D1 > , . . . ,<Dr>) :MKED(<T>) ] 

Get_first  works  similar  to  the  get_fi rstjnark ,  but  as  the  name 
implies  it  does  everything  as  the  latter  except  marking.  Therefore, 
it  is  used  in  iterative  programs  where  value  correlations  within  a 
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relation  are  required.  It  takes  shorter  to  execute  for  each  pass 

than  the  get_fi rstjnark  since  there  is  no  marking  done,  only  the  specified 

domain  values  are  saved  while  the  T  bit  is  reset. 

2. 3. 1.9  SAVE 

<Label>  SAVE  [<R>(<D>) :<QUALIFICATION>] 

This  is  a  special  instruction  for  saving  a  domain  value  from  a 
single  tuple  into  the  RAP  register  REGS.  It  uses  qualification 
evaluation  only  and  no  program  looping  is  needed.  If  there  happens  to 
be  more  than  one  qualifier  the  value  saved  in  REGS  will  be  ambiguous. 

2.3.2  Update  commands:  ADD,  SUB,  MUL,  DIV,  and  REPLACE 

<Label>  <0PR>(T)  [<R>(<D1>( ,<D2>) ) :<QUALIFICATION>][<OPD>] 

where  OPR  is  one  of  the  operators  ADD,  SUB,  MUL,  DIV,  and  REPLACE. 

T  and  D2  are  optional.  Update  commands  in  RAP  are  particularly  very 
efficient  in  the  sense  that  the  operation  is  carried  out  in-place  and 
execution  is  completed  in  one  RAP  memory  cycle  time.  The  instructions 
work  as  follows: 

a)  Domain  D1  in  every  eligible  tuple  is  operated  with  the  OPD. 

OPD  is  a  value  either  passed  as  a  constant  from  the  RAP  program 
or  obtained  from  a  RAP  register.  The  arithmetic  update  can  be 
notated  as  the  assignment  (Dl)  <--  (D1  )0PR(0PD) .  If  opcode  is 
REPLACE,  then  the  update  is  in  the  form  (Dl)  <--  (OPD) 

b)  If  D2  is  present,  then  either  Dl  or  D2  must  be  specified  as  the 
OPD.  The  other  domain  receives  the  result.  Dl  and  D2  can  also 
be  the  same  domain.  D2  option  cannot  be  used  with  the  division 
operati on . 

c)  If  T  is  specified,  then  tuples  are  T-marked  as  updated  so  that 
in  case  of  failures  only  a  partial  backup  would  be  necessary. 
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Division  is  performed  as  an  inverse  multiplication  with  a  fixed 
scale  up  factor.  Negative  numbers  are  represented  in  two's  complement 
form,  but  signed  multiplication/division  is  not  supported.  Indication 
of  an  overflow  error  condition  together  with  its  cell  address  are 
signalled  to  the  controller. 

2.3.3  Set  function  commands 

<Label>  <S0PR>  [<R>(<D>)  :<QUALIFICATION>][<REGFJ>] 

where  SOPR  is  one  of  the  set  function  operators  SUM,  COUNT,  MAX, 

MIN,  or  AVERAGE.  The  opcode  COUNT  counts  eligible  tuples  in  the  relation 
and  places  the  result  in  one  of  the  two  RAP  registers  called  REGF_1 
and  REGF_2.  D  is  not  specified  in  COUNT.  I  specifies  the  register 
number.  Default  (i.e.,  not  specifying  this  parameter)  means  REGF_1 . 

The  other  opcodes  compute  the  specified  function  over  the  numeric 
domain  D  of  the  eligible  tuples.  Each  cell  stores  its  result  in  its 
ALU.  The  set  function  unit  (SFU)  polls  cells  to  compute  the  overall 
result.  The  opcode  AVERAGE  is  executed  as  a  macro  broken  into  operations 
of  SUM  and  COUNT  followed  by  a  special  SFU-divide  instruction. 

2.3.4  Insertion  and  deletion  commands 
2. 3. 4.1  DELETE 

<Label>  DELETE  [<R> : <QUALIFICATION>] 

Tuples  of  relation  R  qualifying  for  deletion  are  delete-flagged 
and  ignored  in  subsequent  operations.  Physical  deletion  (i.e.,  garbage 
collection)  takes  place  in  the  background  at  a  rate  of  a  tuple  per  cell 
per  revolution.  This  operation  is  done  automatically  by  the  garbage 
collection  hardware  without  any  software  aid.  The  data  is  packed  towards 
the  beginning  leaving  the  garbage  accummulated  towards  the  end  of  the 
cell  memory. 


-15- 


2. 3. 4. 2  INSERT 

<Label>  INSERT  [<R>] [<WORKAREA>] 

where  workarea  is  the  front-end  processor's  (i.e.,  supporting 
processor)  program  storage  location  containing  the  tuple  to  be  inserted. 
Storage  allocation  via  this  instruction  is  also  done  automatically  by 
the  hardware.  The  cells  of  the  relation  R  are  examined  serially  for  the 
first  available  one  with  empty  space.  The  tuple  to  be  -Inserted  is  then 
written  from  the  controller  to  the  end  of  the  data.  If  there  is  no  cell 
found  with  available  space  a  new  cell  for  the  relation  is  first  preformated 
and  then  written  with  the  inserted  tuple.  More  on  the  RAP  architectural 
features  with  the  bulk  insertion  capability  can  be  found  in  the  detailed 
documentation  [2]. 

2.3.5  Data  definition  commands 

2. 3. 5.1  DR0P_D0MAIN 

<Label>  DR0P_D0MAIN  [<R>(<D>) :<QUALIFICATION>] 

This  instruction  is  included  for  structural  changes.  All  tuples 
of  the  relation  are  affected,  however  a  previous  marking  must  be  performed 
on  the  relation  for  the  operation  of  this  instruction.  The  domain  (more 
precisely  the  attribute)  D  is  deleted  from  the  stored  tuples  of  the  relation. 

2. 3. 5. 2  DESTROY 

<Label>  DESTROY  [<R> :<CELL( I )>] 

This  instruction  deletes  the  tuples  and  header  of  a  specified 
cell  of  a  relation.  If  the  cell  number  is  not  specified  the  entire 
relation  is  deleted  from  all  the  cells  it  occupies. 
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2. 3. 5. 3  CREATE 

<Label>  CREATE  [<R> :<CELL( I )>][<WORKAREA>] 

One  execution  of  this  instruction  creates  one  cell  for  the  relation 
R.  Empty  tuples  are  preformated  on  the  created  cell.  The  operation  can 
be  directed  to  a  specific  cell  by  specifying  the  cell  number.  Workarea 
is  the  program  storage  location  of  the  supporting  processor  containing 
the  format  of  the  new  relation's  tuples. 

2.3.6  Decision  and  transfer  commands 

2. 3.6.1  TEST 

<Label>  TEST  <T>_RAIL 

where  T  is  restricted  to  denote  only  one  mark  domain.  This 
instruction  tests  the  presence  of  any  T-marked  tuples  in  a  relation. 

If  there  is,  then  the  hardware  indicator  RAIL_STAT(<T>)  is  turned  on 
for  the  corresponding  mark  bit.  Since  the  rail  structure  is  a  bus,  there 
should  be  only  one  relation  set  to  T  bit  at  a  time  if  this  instruction  is 
to  be  used  in  program  loops  based  on  the  result  of  rail  status.  The  result 
of  this  test  is  used  in  the  BC  instruction.  This  instruction  can  be 
simulated  by  a  COUNT  instruction  in  cases  where  multiple  relations  use 
the  same  mark  bit  and  program  looping  is  necessary.  COUNT  should  be 
followed  by  a  BC  for  testing  the  result  in  the  REGF  register. 

2. 3. 6. 2  BC 

<Label>  BC  <ADDRESS> ,<C0NDITI0N> 

where  BC  is  the  abbreviation  for  "branch  on  condition".  This 
instruction  works  both  as  conditional  or  unconditional  branch  instruction 
depending  on  the  following.  The  condition  can  be  one  of: 
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a)  RAIL_STAT (<T>)  --  presence  of  T-marked  tuples  in  the  relation 

b)  <REG><C0MP><0PR>  --  a  comparison  between  any  RAP  register  and 

an  OPD.  OPD  can  be  a  constant,  literal,  or  another  RAP 
register;  COMP  can  be  =,  /,  <,  <,  >,  or  >. 

If  the  condition  evaluated  is  true  then  the  control  is  transferred  to 
the  instruction  whose  label  matches  the  ADDRESS,  otherwise  the  next 
instruction  following  BC  is  given  control.  If  no  condition  is  present, 
i.e.,  a  null  condition,  then  the  instruction  is  treated  as  an  unconditional 
branch . 

2. 3. 6. 3  EOQ 

<Label>  EOQ 

This  indicates  end  of  a  RAP  query  program. 
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3.  TEMPLATES  FOR  THE  RELATIONAL  ALGEBRA  OPERATIONS 

In  this  section  we  will  describe  writing  templates  in  the 
RAP  language  for  performing  the  relational  algebra  operations.  These 
templates  are  included  mostly  from  a  theoretical  point  of  view.  If  one 
can  construct  RAP  programs  for  all  the  operations  of  the  relational 
algebra  as  specified  by  Codd  [10]  one  can  prove  the  relational  complete¬ 
ness  in  an  equivalent  way  [7]  to  the  direct  proof  shown  by  Codd  for  the 
relational  calculus.  As  far  as  query  processing  efficiency  is  concerned 
however,  RAP  has  powerful  primitives  that  can  do  the  same  operations  more  directly 
and  efficiently.  Examples  to  this  are  crossjnark  and  get_first  type 
commands,  direct  and  in-place  selection,  update,  and  set  function 
computation  capabilities.  In  order  to  describe  these  features  clearer, 
some  query  examples  are  provided  in  the  appendix-3  so  that  the  reader, 
after  reading  the  instruction  descriptions  and  the  RAP  templates,  can 
have  a  familiarity  with  programming  DBMS  applications  in  RAP. 

3.1  Specifying  qualifications  with  set  operations 

Before  going  into  the  relational  templates  we  will  first  present 
examples  of  constructing  instruction  qualifications  with  set  operations. 

Let  us  denote  two  subsets  of  a  relation  by  SETA  and  SETB  and  assume  that 
their  values  are  identified  by  tl  and  t2  marked  tuples  respectively. 

The  following  qualifications  can  be  specified: 

a)  COMPLEMENT - .  SETA 

qualification:  !JNMKED(tl) 

b)  UNION  --  SETA  U  SETB 
qualification:  MKED(tl)  v  MKED(t2) 

c)  INTERSECTION  --  SETA  n  SETB 

qualification:  MKED(tlt2)  or  MKED(tl)  n  MKED(t2) 

d)  DIFFERENCE  --  SETA  -  SETB 
qualification:  MKED(tl)  ^  UNMKED(t2) 
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This  capability  enables  implementation  of  various  RAP  mapping  operations 
as  well  as  the  operations  of  the  relational  algebra. 

3.2  Templates 
3.2.1  Union 

Algebra:  R  U  S  Calculus:  (r:reR  v  reS) 

In  all  set  operations  we  exploit  the  basic  fact  that  a  relation  is 
a  set  of  tuples.  The  relations  used  as  operands  in  the  union  operation 
can  be  different  relations  with  compatible  domains  (i.e.  the  same  list  of 
domains)  or  subsets  of  a  single  physical  relation.  We  will  present  the 
union  operation  with  sets  of  tuples  in  the  relations  being  disjoint  and 
non-di sjoi nt. 

The  union  operation  can  be  performed  either  physically  or  implicitly. 
In  the  former  case,  the  relations  should  be  read  out  and  assembled  in  the 
supporting  processor.  In  the  latter,  the  union  is  reflected  in  the  mark 
bits  which  can  be  used  without  transferring  any  data.  The  following  RAP 
programs  will  illustrate  the  two  union  operations  with  disjoint  and  non- 
disjoint  relations. 

a)  Relations  R  and  S  are  disjoint 

Physical  union 

READ  [R][W0RKAREA(1 )] 

READ  [S][W0RKAREA(2)] 

EOQ. 

Implicit  union 
MARK  (tl)  [R] 

MARK  (tl)  [S] 

EOQ. 


-20- 


b)  Relations  are  non-disjoint 

If  it  is  not  known  that  the  relations  are  disjoint  a  check  out  procedure 
can  be  written  to  eliminate  the  duplicate  tuples  from  the  result.  For 
illustration  purposes  we  will  show  a  check  out  procedure  on  a  single  domain. 
In  exhibit-1  of  the  appendix-1  we  show  a  more  general  procedure  for  checking 
all  domains.  (Comments  for  all  RAP  programs  are  placed  between  /*  and  */ 
del imi ters . ) 

Physical  union  between  relations  R  and  S  with  compatible  domain  D1 : 


MARK  (tl)  [R] 

/★preprocess  for  loop*/ 

LI  GET_FIRST  [R( D1 ) : MKED( tl ) ] 

/*read  into  RAP  register  the  domain  value 

contained  in  the  first  tl  marked  tuple*/ 

MARK  (t2)  [S:D1  =  (REGCJ)] 

/*mark  matching  tuples  in  S*/ 

TEST  t2_RAIL 

/*any  match?*/ 

BC  SKIPl  ,RAIL_STAT(t2) 

/*Yes*/ 

READ  [R:UNMKED(AB)][WORKAREA] 

/*No,  output*/ 

BC  SKIP2 


SKIPl  RESET  (t2)  [S] 

/*Clear  work  mark  bit*/ 

SKIP2  MARK  (t3)  [R:UNMKED(tlt3)] 

/*Mark  current  tuple  as  processed*/ 

TEST  tl_RAIL 

/*Any  more  tuples  to  be  processed?*/ 

BC  LI ,RAIL_STAT(tl ) 

/*Yes  repeat  the  loop*/ 

RESET  (t3)  [R] 

/*Clean  up*/ 

READ  [S][W0RKAREA] 

/*Read  relation*/ 

EOQ 

For  implicit  union  the  read  instructions  can  be  replaced  by  mark 


instructions  that  would  use  a  different  mark  domain  than  those  already 
used  in  the  program. 
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3.2.2  Intersection 

Algebra:  R  n  S  Calculus:  (r:reR  a  reS) 

As  will  be  shown  in  section  3.1,  set  operations  between  domains  can  easily 
be  specified  in  a  RAP  instruction  qualification.  Intersection  between 
relations  involves  checking  out  all  domains  in  the  relations.  A  RAP  program 
for  doing  intersection  would  be  similar  to  that  of  non-disjoint  union,  except 
in  this  case  a  negative  logic  would  be  used,  that  is,  tuples  of  interest 
are  those  that  are  non-disjoint.  A  general  program  for  doing  intersection 
is  shown  in  exhibit-2  of  the  appendix-1. 

3.2.3  Difference 

Algebra:  R  -  S  Calculus:  (r:r£R  a  r  ^  S) 

This  operation  is  also  similar  to  the  set  operations  discussed  so  far. 

In  programming  for  RAP,  for  each  tuple  of  one  relation  a  check  is  made  to 
see  whether  it  is  in  the  other  relation.  If  it  is,  it  is  ignored,  otherwise 
it  is  read  out.  A  general  version  of  such  a  RAP  program  is  given  in  the 
exhibit-3  of  the  appendix-1. 

3.2.4  Cartesian  product 

Algebra:  R  *  S  Calculus:  ((rl|s):reR  a  seS) 

In  the  following  RAP  program  demonstrating  the  Cartesian  product,  for 
every  tuple  of  relation  R  all  the  tuples  of  relation  S  are  read  out  in  a 
pairwise  fashion.  That  is,  the  current  R  tuple  is  read  out  for  every  S 
tuple  read.  This  operation  is  repeated  until  all  tuples  of  R  are  dealt 
with  in  the  same  manner.  The  result  is  all  possible  pairings  of  tuples 

between  the  two  relations.  Physical  joining  of  the  tuples  in  the  support 

processor  can  be  accomplished  by  proper  indexing  through  the  workareas 
allotted  for  the  output  operations. 
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The  RAP  program. 


MARK  (tl)  [R] 

/*preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

LI  GET_FIRST  [R(D1 ) :MKED(tl )] 

/*tl  unmark  the  first  tl  marked  tuple  of 

relation  R  (the  D1  value  saved  is  not  used)*/ 

MARK  (t2)  [S] 

/*preprocess  for  inner  loop  which  reads  the 

current  tuple  of  R,  repeatedly,  for  each 

successive  tuple  of  S*/ 

L2  READ  [R:UNMKED(tlt4)][W0RKAREA] 

/*Read  current  tuple  of  R*/ 

GET_FIRST  [S(Dl):MKED(t2)] 

/*proceed  thru  S  as  in  LI*/ 

READ  [S:UNMKED(t2t3)][W0RKAREA] 

/*Read  out  the  S  tuple  just  unmarked.  This 

tuple  together  with  the  current  tuple  of  R 

make  up  one  of  the  cross  product  relation*/ 

MARK  (t3)  [S:UNMKED(t2t3)] 

/*t3  mark  the  S  tuple  just  read*/ 

TEST  t2_RAIL 

/*Any  more  S  tuples?*/ 

BC  L2,RAIL_STAT(t2) 

/*Yes,  repeat  the  loop*/ 

/*End  of  the  inner  loop*/ 

/*Housekeeping  before  we  can  proceed  to 

the  next  tuple  of  relation  R*/ 

RESET  (t3)  [S] 

/*Clear  work  mark  bit*/ 

MARK  (t4)  [R:UNMKED(tlt4)] 

/*Mark  the  processed  R  tuple*/ 

TEST  tl_RAIL 

/*Any  more  R  tuples?*/ 

BC  LI  ,RAIL_STAT(tl) 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been  processed. 

RESET  (t4)  [R] 
EOQ 


Clean  up  and  exit*/ 
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Another  way  without  writing  a  RAP  program  is  just  to  read  the  relations 
out  and  do  the  operation  in  the  front-end  processor. 

3.2.5  e-Join  (where  0  e (<,<,=  ,>,>,/) ) 

Algebra:  R[M  e  N]S  Calculus:  ((rlls):r£R  a  s  e  S  a  r[M]  e  s[N]) 

(where  M  and  N  represent  subset  or  list  of  domain  names  for  the  relation- 
R  and  S) 

As  a  direct  consequence  of  relational  mathematics,  it  has  been  customary 
to  think  of  e-join  (specifically  equality  ("=")  or  natural  join)  as  a  part 
of  the  basic  operations  of  the  relational  data  base  management.  By  join 
here,  we  mean  the  physical  join  which  is  generally  understood  as  the  forming 
of  a  new  relation  through  tuple  concatenation  by  marking  common  domains. 

However,  physical  join  is  not  necessary  in  answering  most  queries.  Only 
in  the  case  where  two  domains  from  different  relations  are  required  to  be 
side  by  side  need  to  form  the  physical  join.  In  fact,  recent  research 
indicates  that  physical  join  might  result  in  undesirable  semantic  properties 
and  that  it  can  be  avoided  by  proper  data  base  design  [5,12].  In  RAP, 
there  is  a  similar  operation  called  the  cross_mark  which  does  implicit  join 
between  relations  i.e.,  the  selection  of  tuples  in  one  relation  based  on 
selected  tuples  in  another.  A  physical  join  can  be  programmed  in  RAP  by 
the  repeated  use  of  the  implicit  joint  operation.  However,  RAP  version  of 
implicit  join  is  adequate  for  answering  queries.  The  capability  of  synthesizing 
physical  join  will  be  demonstrated  mostly  for  the  sake  of  compatibility  with 
the  relational  algebra, 
a)  Implicit  join 

Any  of  the  following  RAP  commands  can  be  used  depending  on  the  situation: 

i)  CROSS__MARK  (tl)  [R1:D1  6  R2 .  D2]  [R2 .  MKED(  t2 )  ] 

ii)  CR5_C0ND_MARK  (tl[tr])  [R1:D1  6  R2 . D2] [R2 . MKED( t2 ) ] 
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iii)  GET_FIRST_MARK  (tl)  [R( D1 , . . . ,Dr) :Da  6  Db][MKED(t2)] 

The  basic  idea  in  the  crossjnark  command  is  to  take  second  relation's 
specified  domain  values  and  use  them  as  a  disjunctive  mapping  criteria  in  the 
form  of  marking  comparands  to  the  second  relation.  The  get_fi rstjnark 
command  is  similar  to  the  crossjnark  command  and  does  an  implicit  join 
within  a  single  relation  (i.e.,  joining  a  relation  to  itself  on  a  common  or 
different  compatible  domains).  This  instruction  can  also  save  domain 
values  into  RAP  registers.  The  crs_condjnark  command  is  a  special 
form  of  the  crossjnark  command.  It  is  used  in  doing  repeated  mappings 
into  the  same  relation.  It,  by  its  conditional  setting/resetting 
capability,  accomplishes  the  result  of  successive  implicit  join  operations 
between  a  relation  and  the  result  of  a  previous  implicit  join.  These 
instructions  are  also  useful  for  general  forms  of  the  restriction  operation. 

b)  Physical  join 

Assume  two  relations  R  and  S.  The  following  RAP  program  will  demonstrate 
programming  for  physical  join.  For  each  tuple  of  R,  all  e-satisfying  tuples 
of  S  are  read  out  together  with  the  tuple  of  R.  This  process  is  repeated 
until  all  R  tuples  are  dealt  with. 

The  RAP  program. 

MARK  (tl)  [R]  /*Preprocess  for  loop*/ 


/*Loop  thru  tuples  of  relation  R*/ 


LI  GET_FIRST  [R( D1 ) : MKED( tl ) ] 


/*Read  in  the  domain  value  of 


the  current  tuple*/ 


MARK  (t2)  [S:D1  0  (REGC_1)]  /*Mark  all  tuples  of  S  with  domain  values 


satisfying  the  join  condition*/ 


TEST  t2  RAIL 


/*Any  such  S  tuple?*/ 


BC  L2,RAIL  STAT(t2) 


/*Yes*/ 
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BC  SKIP 


L2  MARK  (t3)  [S : UNMKED( t2) ] 

RDLOOP  READ  [R; UNMKED( tlt4) ] [WORKAREA] 
GET_FIRST  [S(D1 ) :MKED(t2)] 

READ  [S:UNMKED(t2t3)][WORKAREA] 


/*No*/ 

/*Now  read  out  alternately,  the  current  R 
tuple  and  one  of  the  t2  marked  S  tuple 
until  all  t2  marked  S  tuples  have  been 
processed*/ 

/★Preprocess  for  loop*/ 

/*Read  the  R  tuple*/ 

/*t2  unmark  the  first  t2  marked  S  tuple. 
(The  D1  value  saved  is  not  used)*/ 

/*Read  out  the  S  tuple  just  t2  unmarked*/ 


MARK  (t3)  [S:UNMKED(t2t3)] 
TEST  t2_RAIL 
BC  RDLOOP, RAIL_STAT(t2) 
RESET  (t3)  [S] 


SKIP  MARK  (t4)  [R:UNMKED(tlt4)] 
TEST  tl_RAIL 
BC  LI  ,RAIL_STAT(tl ) 


RESET  [t4]  [R] 
EOQ 


/*Mark  it  as  processed*/ 

/*Any  more  S  tuples  to  be  processed?*/ 

/*Yes,  repeat  the  loop*/ 

/*No,  clear  work  mark  bit*/ 

/*Housekeeping  before  we  can  proceed  to 
the  next  tuple  of  the  relation  R*/ 

/*Mark  tuple  as  processed*/ 

/*Any  more  R  tuples  to  be  processed?*/ 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been  processed. 
Clean  up  and  exit*/ 


The  join  can  be  accomplished,  similar  to  that  shown  for  the  Cartesian  product, 
by  proper  indexing  through  the  work  areas  reserved  for  the  read  operations. 

If  M  and  N  represent  list  of  domains  rather  than  a  single  domain  as  program 
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above  assumed  a  series  of  0  comparisons  must  be  met  conjunctively  by  the 
satisfying  tuples.  The  procedure  for  checking  out  multiple  domains  is  the 
same  as  used  in  the  exhibits  1  through  3  of  the  appendix-1.  Also  similar 
to  the  case  of  Cartesian  product,  relations  can  be  read  out  and  the  join 
executed  in  the  front-end  processor. 

3.2.6  Restriction 

Algebra:  R[M  0  N]  (where  0  e  (<,<,=,>,>,/)  and  M,  N  represent  lists 

of  domain  names) 

Calculus:  (r:r£R  a  r[M]  0  r[N]) 

Restriction  operation  is  a  limited  0  comparison  of  the  values  of  two  or 
more  domains  in  the  same  tuple.  However,  in  practice  the  second 
domain  list  (taken  as  the  criterion)  is  usually  a  small  (sometimes  a  single 
value)  relation  introduced  externally  whose  domains  are  a  subset  of  R  and 
treated  in  a  join  that  subsets  tuples  of  R.  RAP  programs  will  show  different 
forms  of  the  restriction. 

a)  Simple  restriction 
The  RAP  program 

MARK  (tl)  [R:D  0  v] 

consists  of  a  single  instruction  v  being  the  external  criterion. 

b)  Restriction  based  on  one  pair  of  domains  D1  and  D2  in  the  same  relation 
(i.e.,  M,  N  =  1).  This  form  of  restriction  is  referred  to  as  selection  by 
Codd  [10]. 

MARK  (tl)  [R]  /*Preprocess  for  loop*/ 

LI  GET_FIRST  [R(D1 ,D2) :MKED( tl )]  /*Read  into  REGC_1  ,2  the  two  domain  values 

of  the  first  tl  marked  tuple*/ 

BC  RDTUPLE ,  ( REGC_1 )  0  (REGC_2)  /*Go  to  RDTUPLE  if  restriction  condition  is 

satisfied*/ 


BC  SKIP 


/*If  not,  ignore  the  tuple*/ 
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RDTUPLE  READ  [R: UNMKED( tlt4) ] 

SKIP  MARK  (t4)  [R:UNMKED(tlt4)] 


/*Read  current  tuple*/ 


/*Mark  tuple  as  processed*/ 


TEST  tl  RAIL 


/*Any  more  tuples  to  be  processed?*/ 


BC  LI ,RAIL_STAT(tl) 
RESET  (t4)  [R] 


/*Yes,  repeat  the  loop*/ 


/*A1 1  tuples  processed*/ 


EOQ 


/*Exit*/ 


In  exhibit-4  of  the  appendix-1  restriction  on  multiple  domains  (i.e.,  M,  N  >  1) 
is  demonstrated. 

c)  General  Boolean  restriction  on  Di  e  v  conditions  where  Di  is  a  domain 
and  V  is  a  value  is  handled  by  the  general  qualification  logic  of  each 
instruction. 

3.2.7  Projection 

Algebra:  R[M]  Calculus:  (r[M]:r£R) 

Projection  involves  creating  a  subset  relation  from  a  larger  relation 
by  including  only  a  subset  of  the  domains  (mostly  a  single  domain).  In  the 
process,  resulting  duplicate  tuples  are  eliminated.  In  RAP,  this  requires 
an  iterative  program  which  repeats  as  many  times  as  there  are  distinct  values 
in  the  projected  domain.  If  the  result  is  not  read  out  it  can  be  marked.  In 
the  latter  case,  there  is  the  advantage  of  being  able  to  access  unprojected 
co-domains  of  the  larger  relation.  In  programming  for  projection  with  RAP 
the  special  case  of  crossjnark  type  instruction  get_fi rstjnark  is  used. 

In  the  following  we  will  present  an  example  of  projection  on  a  single  domain. 
The  exhibit-5  of  appendix-1  gives  a  more  general  case  of  projection  with 
multiple  domains. 

Example:  Assume  relation  R  has  a  domain  Di  which  is  a  prime  attribute 
and  part  of  the  relation's  composite  key.  If  R  is  to  be  projected  over  Di , 
lesser  number  of  tuples  would  result  due  to  elimination  of  duplicate  values 
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required  in  forming  the  composite  key.  Figure  4  illustrates  an  example 
projection  operation.  Only  values  of  domain  Di  are  shown  with  respective 
tuple  numbers.  A  subset  of  relation  R,  as  shown  by  double  markings  in  Figure 
4. a,  is  to  be  projected  over  domain  Di  whose  values  are  listed  on  the  second 
left  column.  A  trace  of  the  projection  iteration,  whose  program  in  RAP 
is  presented  below,  is  shown  in  the  subsequent  stages  of  the  same  figure. 

A  dash  in  mark  bit  positions  is  used  to  signify  a  change  resulting  in  an 

iteration  just  completed.  The  RAP  program  given  below  can  be  studied  by 
following  the  trace  of  the  example  in  Figure  4. 


The  RAP  program. 

MARK  (t2)  [R:MKED(tl)] 

/★Preprocess  for  loop  by  t2  marking 

the  subset  relation  indicated  by  tl 

marki ngs*/ 

LI  GET_FIRST_MARK  (t3)  [R:Di  =  Di]  [MKED(tl)] 


/*t3  mark  those  tuples  with  the  same  Di 

value  as  the  first  tl  marked  tuple  and 

reset  its  mark  bit*/ 

TEST  t3_RAIL 

/*Any  duplicate?*/ 

BC  L2,RAIL_STAT(t3) 

/*Yes*/ 

BC  L3 

/*No*/ 

L2  RESET  (tlt2t3)  [R] 

/*Reset  all  mark  bits  of  tuples 

just  t3  marked*/ 

L3  TEST  tl_RAIL 

/*Any  more  tuples  to  be  processed?*/ 

BC  LI  ,RAIL_STAT(tl ) 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  with  unique  Di  values  are 

left  t2  marked.  They  can  be  left  for 

future  processing  or  read  out  as  the 

following  code  shows*/ 

Tuple  no. 

Di  value 

tl 

t2 

t3 

tl 

t2 

t3 

tl 

t2 

t3 

1 

20 

X 

X 

20 

X 

20 

X 

Subset  relation 
is  double 

2 

20 

20 

20 

marked.  Extra 

\ 

mark  bit  is 
needed  to 

3 

30 

X 

X 

30 

X 

X 

30 

— 

X 

identify  the 
subset. 

4 

30 

X 

X 

30 

X 

X 

30 

X 

X 

5 

30 

X 

X 

30 

X 

X 

30 

X 

X 

X 

4a . 

4b 

4c . 

tl  t2  t3  tl  t2  t3 


20 

X 

20 

X 

> 

result  is 
two  unique 

20 

20 

y  i  terns 
found  in 

30 

X 

30 

X 

the  subset 

30 

- 

- 

-  30 

> 

30 

-  30 

4d.  4e. 


Figure  4.  An  example  projection 
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READ  [R:MKED(t2)][W0RKAREA] 

EOQ 

The  get_fi rstjnark  and  get_first  instructions  provide  tuple  iterative 
programming  feature  to  RAP.  The  programs  given  in  the  earlier  templates, 
especially  those  given  in  the  appendix-1,  demonstrated  the  use  of  these 
instructions  where  tuple  iterations  were  required.  These  instructions 
are  special  cases  of  crossjnark  type  instructions.  The  former  provide 
the  power  of  "self-mapping"  or  "self-restriction"  capability  to  processing 
a  relation.  More  specifically,  sequential  oriented  free  variable  [6] 
applications  where  tuples  of  a  relation  are  correlated  require  programmed 
loops  by  the  use  of  these  instructions.  Data  base  operations  of  grouping, 
projection,  and  correlation  (i.e.,  processing  on  self-looped  structures) 
are  of  this  nature.  Examples  shown  in  the  queries  Q9  through  Qll  of  the 
appendix-3  demonstrate  RAP  programming  for  such  operations. 

3.2.8  Division 

Assume  two  relations:  R(D1 ,D2,. . . ,D7,D01 ,D02,. . . ,D08) 

S(D1  ,D2,. . .  ,D8,. . . ) 

Algebra:  R[D1 ,D01 ]/S[Dl  ] 

Calculus:  (r[Dl]:reRA  (y :  (r[Dl  ]  ,y  )eR[Dl  ,D01  ] )  ^  s[d1  ] ) 

Although  it  is  known  that  the  division  operation  can  be  achieved  by 
the  primitive  relational  algebra  operators,  we  feel  that  an  explicit 
treatment  will  be  useful.  Programs  accomplishing  divisions  in  RAP  are 
non-trivial,  however  understanding  the  process  is  useful  because  it  is 
the  tool  for  programming  where  universal  quantification  is  involved.  In 
the  following  we  will  present  two  templates;  the  first  one  describes  the 
simplest  case,  the  second  one  demonstrates  a  case  extendible  to  the 
general  division.  The  exhibit-6  of  appendix-1  shows  a  program  for  general¬ 


ized  division. 
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a)  The  RAP  program  for  the  simplest  case  of  division  will  be  as  follows 
We  will  first  project  relation  S,  the  divisor,  on  domain  D1 .  For 
each  unique  D1  value  of  relation  R,  the  dividend,  the  tuples  with  that  D1 
value,  but  with  unique  DOl  value  will  be  t2  marked.  If  the  number  of  t2 
marked  tuples  is  greater  than  or  equal  to  the  number  of  unique  D1  values 
of  the  divisor,  perform  a  crs_condjnark  and  then  count  the  number  of  t2 
marked  tuples.  If  the  count  is  equal  to  the  number  of  unique  D1  values 
in  the  divisor  the  D1  value  of  the  dividend  is  read  out.  The  process  is 
repeated  for  all  unique  values  in  the  dividend. 

(Project  S  on  D1  --  program  is  not  shown,  unique  values  will  be  t5  marked.) 
COUNT  [S:MKED(t5)]  /*Count  the  number  of  t5  marked  tuples 

and  place  the  result  in  REGF_1*/ 

MARK  (tl)  [R]  /*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation*/ 

LO  GET_FIRST_MARK  (t2t3)  [R(D1):D1  =  D1  ]  [MKED(  tl ) ] 

RESET  (tl)  [R:MKED(t2t3)] 


LI  GET_FIRST_MARK  (t4)  [R:D01  = 
RESET  (t2t3t4)  [R] 

TEST  t3_RAIL 

BC  LI ,RAIL_STAT(t3) 

COUNT  [R:MKED(t2)][2] 

BC  L2,(REGFJ)  >  (REGFJ) 


/*Group  those  with  the  same  D1  value*/ 
/*Also  tl  unmark  them  so  that  they 
should  not  be  picked  up  again*/ 

/*t2  mark  only  those  t2t3  marked  tuples 
that  have  unique  DOl  value*/ 
D01][MKED(t3)] 

/*Unique  tuples  are  left  t2  marked*/ 

/*Count  those  unique  tuples  and  place  the 
result  into  REGF_2*/ 

/*If  the  number  of  t5  marked  tuples  is 


greater  than  the  number  of  t2  marked 
ones,  skip*/ 
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L2 


/*Otherwise,  crs_cond_mark  into  the 
t2  marked  tuples  of  relation  R*/ 

MARK  (t4)  [S:MKED(t5)] 

CRS_COND_MARK  (t2[t3])  [R:D01  =  S.Dl ][S.MKED(t4)] 

/*After  this,  those  unqualified  are 
t2  unmarked*/ 


COUNT  [R:MKED(t2)][2] 

BC  L2,(REGFJ)  /  (REGF_2) 


READ_REG  [(REGCJ)] 


RESET  (t2)  [R] 

TEST  tl_RAIL 
BC  LO,RAIL_STAT(tl) 


RESET  (t5)  [S] 
EOQ 


/*If  the  number  of  t2  marked  tuples 
left  is  not  equal  to  the  number  of  t5 
marked  ones,  skip*/ 

/*So  far  all  is  well.  Read  the  D1  value 
saved  in  REGC_1*/ 

/*Housekeeping  before  we  can  proceed  to 
to  the  next  tuple  of  relation  R  that 
has  the  next  unique  D1  value*/ 

/*Any  more  R  tuples  to  be  processed?*/ 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been 
processed.  Clean  up  and  exit*/ 


b)  Next  example  will  be  the  RAP  program  for  doing  division  without  using 
the  crs_cond_mark  instruction.  This  example  helps  to  understand  the  general 
case  presented  in  the  appendix-1.  Crs_condjnark  can  only  be  used  if  the 
values  in  the  image  set  are  unique.  If  only  a  single  domain  was  involved, 
a  projection  could  easily  be  done  so  that  crs_cond_mark  could  then  be  used. 
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This  was  shown  in  the  simplest  case  above. 

The  RAP  program  for  division  without  the  crs_condjnark: 

Similar  procedure  to  the  previous  one  is  used.  Instead  of  using  the 
crs_cond_mark,  all  DOl  values  are  compared  with  the  unique  D1  value  of  the 
divisor.  If  a  match  is  found  for  all  the  divisor's  D1  domain  values,  then 
the  respective  D1  value  of  the  dividend  is  read  out. 

The  RAP  program. 

(Project  S  on  D1--  program  is  not  shown,  unique  values  will  be  t5  marked.) 
COUNT  [S:MKED(t5)]  /*Count  the  number  of  t5  marked 

tuples  and  place  the  result  in  REGF_1*/ 
MARK  (tl)  [R]  /*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

LO  GET  FIRST  MARK  (t3)  [R:D1  =  D1 ] [MKED( tl ) ] 

/*Process  sequentially  tuple  at  a  time 
and  each  time  group  tuples  with  respect 
to  D1  values*/ 

/*If  number  of  t5  marked  S  tuples  is 
greater  than  number  of  t3  marked  tuples 
skip  the  checking  since  will  fail*/ 
/*Loop  thru  all  t5  marked  tuples  of 
relation  S*/ 

/*Preprocess  for  loop*/ 

/*Save  D1  value  of  the  first  t4  marked 
tuple*/ 

MARK  (t6)  [R:D01  =  (REGCJ)  a  MKED(t3)] 

/*t6  mark  all  t3  marked  tuples  of  relation 
R  with  DOl  values  matching  the  D1  value 


COUNT  [R:MKED(t3)][2] 

BC  SKI  PI  ,(REGFJ  )  >  (REGF_2) 


MARK  (t4)  [S:MKED(t5)] 

LLl  GET_FIRST  [S(D1 ) :MKED(t4)] 
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TEST  t6_RAIL 

saved  in  REGC  1*/ 

/*Any  such  tuple?*/ 

BC  LL2,RAIL_STAT(t6) 

/*Yes*/ 

RESET  (t4)  [S] 

/*No,  reset  mark  bit  t4*/ 

BC  SKIPl 


LL2  RESET  (t6)  [R] 

/*We  have  found  a  match  for  the  current 

tuple  of  relation  S.  Now  repeat  with 

the  next  t5  marked  tuple  (which  is  also 

the  first  t4  marked  tuple)*/ 

/*Clear  the  work  bit*/ 

TEST  t4_RAIL 

/*Any  more  S  tuples  to  be  checked?*/ 

BC  LLl ,RAIL_STAT(t4) 

/*Yes,  repeat  the  loop*/ 

/*We  have  found  a  match  for  all  the  t5 

marked  tuples  of  relation  S.  So  read 

out  the  D1  value  of  the  current  tuple  of 

relation  R*/ 

READ  [R(D1) :UNMKED(tlt2)][W0RKAREA] 


/*Housekeeping  before  we  can  proceed  to 

the  next  tuple  of  relation  R*/ 

SKIPl  riARK  (t2)  [R:MKED(t3)] 

/*t2  mark  all  R  tuples  just  processed*/ 

RESET  (tlt3)  [R;MKED(t3)] 

/*Clear  work  mark  bits*/ 

TEST  tl_RAIL 

/*Any  more  R  tuples  to  be  processed?*/ 

BC  LO,RAIL_STAT(tl) 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been 

processed.  Clean  up  and  exit*/ 

RESET  (t2)  [R] 
RESET  (t5)  [S] 
EOQ 
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Division  is  a  useful  operation  especially  when  quantifiers  (i.e.,  use 
of  ALL,  ONLY,  etc.  in  English  query  specification)  are  needed  to  compare 
sets  of  data  with  respect  to  set  operations  of  £,  £,  =,  c,  and  3. 

Examples  of  RAP  programming  with  respect  to  quantification  as  used  in  a 
high  level  query  language  called  SYNGLISH  can  be  found  in  earlier 
documentation  [4].  One  typical  example  from  this  source  is  given  in  Q12 
of  the  appendix-3. 

3.3  Other  programming  features  with  RAP 

There  are  certain  desirable  features  in  data  processing  that  at  times 
one  might  want  to  have  them  done  directly  by  RAP.  Following  features  are 
of  this  nature: 

a)  sorted  output 

b)  non-trivial  domain  comparisons  such  as  (Da)  >  (Db)  +  c, 
where  Da  and  Db  are  domains  and  c  is  an  external  constant 

c)  evaluation  of  an  intermediate  arithmetic  expression  to  be  used 
for  update  or  comparison  purposes 

d)  ability  to  store  and  compare  long,  variable  length  alphanumeric 
fields  directly. 

These  features  are  not  essential  requirements  for  the  workings  of  a  RAP 
cell  and  its  primitives,  and  therefore  not  included  in  the  direct  hardware 
implementation.  However,  the  following  illustrations  might  help  the  reader 
to  see  that  the  language  is  powerful  enough  to  program  many  desirable  features. 

RAP  program  for  sorted  output  --  in  ascending  order. 

LI  MIN  [R(Di) :UNMKED(t2)]  /*Relation  R,  domain  Di*/ 

MARK  (tlt2)  [R:Di  =  (REGFJ)] 

TEST  tl_RAIL 
BC  L2,RAIL_STAT(tl) 

READ  [R:MKED(tl)] 


/*Tests  whether  the  last  run  was  the  end*/ 
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L2 


BC  LI 

RESET  (t2) 
EOQ 


Similarly,  maximum  can  be  used  when  descending  order  is  required. 

For  doing  the  operations  stated  in  (b)  &  (c)  above,  a  dummy  domain 
must  be  reserved  for  the  relation  as  an  extra  column.  This  is  because 
result  of  RAP  arithmetic  between  two  operands  replaces  one  of  the  operands 
permanently  --  undesirable  in  intermediate  type  operations.  The  following 
RAP  code  demonstrates  use  of  dummy  domain  as  a  work  space. 


REP  [R(Db,DUMMY)][Db] 

ADD  [R(DUMMY)][c] 

SUB  [R(Da,DUMMY)][Da] 

MARK  (tl)  [R: DUMMY  <  0] 

SUB  [R( DUMMY, DUMMY)] [DUMMY] 


/*DUMMY  ^  Db*/ 

/*DUMMY  ^  DUMMY  +  c*/ 

/*DUMMY  ^  DUMMY  -  Da*/ 

/*Mark  those  that  satisfy  the  comparison 
"Da  -  Db  >  c"  between  domains  a  and  b*/ 
/*Clear  the  domain  to  zeros  by  subtracting 
it  from  itself  (it  could  also  be  done  by 
replace  by  zero  operation*/ 


EOQ 


The  feature  required  in  (d)  is  currently  being  considered  by  the  RAP 
project.  Without  it,  either  encoding  (such  as  by  pattern  subsitution  or  else) 
or  direct  representation  by  concatenating  several  domains  to  hold  the  data 
are  possible  solutions.  In  the  latter  case,  searches  of  long  fields  can 
be  done  incrementally  by  the  use  of  the  mark  instruction  --  k  characters 
can  be  searched  in  each  revolution. 

Finally,  a  comment  is  in  order  for  the  use  of  mark  bits.  Although 
four  mark  bits  are  sufficient  to  carry  out  all  RAP  operations,  in  certain 
programs  especially  those  involving  division  and  quantification  between 
several  relations  more  mark  bits  may  be  needed.  Also,  for  multiprogramming 
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a  RAP  device,  we  partition  the  set  of  mark  bits  between  concurrent 
users  [2,11].  Therefore,  whenever  a  mark  bit  limitation  arises  one 
possible  solution  is  to  execute  the  program  incrementally.  An  example 
to  this  can  be  to  save  bits  occupied  by  projection  operations.  Physical 
projections  can  be  formed  in  the  support  processor  by  reading  out  marked 
projection  results  from  RAP.  Results  can  be  reinserted  into  RAP  to 
continue  the  program. 

3.4  Tabular  summary  of  instructions 

In  table-1  RAP  instructions  are  listed.  For  each  instruction, 
information  corresponding  to  instruction  group,  template  type,  and  number 
of  revolutions  for  execution  are  provided. 
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4.  SUMMARY 

In  this  paper  a  complete  documentation  of  the  RAP  assembler  language 
is  presented.  RAP  program  templates  were  then  presented  for  the  relational 
algebra  to  demonstrate  the  relational  completeness  of  the  RAP  instruction 
set.  As  can  be  seen  in  the  templates,  RAP  assembler  is  a  high  level  language 
for  implementing  DBMS  operations.  In  fact,  it  can  be  called  a  "DBMS 
assembler"  since  it  is  directly  assembled  into  the  RAP  data  base  machine 
code . 

In  studying  this  language  the  reader  can  also  gain  insight  into  the 
properties  of  the  RAP  data  base  machine.  RAP  architecture  and  operations 
are  specifically  tailored  for  executing  the  instruction  set.  This 
instruction  set  is  designed  to  be  complete  for  the  requirements  of  data 
base  management. 

Programming  with  RAP  requires  some  training,  however  it  is  not 
difficult  since  the  language  is  high  level  and  its  syntax  resembles  the 
basic  structure  of  a  query.  For  casual  users,  RAP  can  be  used  to  efficiently 
implement  higher  level  user  languages.  Two  examples  can  be  given  in  this 
respect.  One  is  a  preliminary  study  of  a  Synthetic  English  Query  Language 
for  RAP  [4]  and  the  other  is  the  Project  RAP's  user  language.  In  the 
latter  the  SEQUEL  language  is  being  translated  into  the  RAP  assembler. 

A  subset  of  SEQUEL  is  now  demonstratable.  Both  of  these  studies  indicate 
that  support  of  casual  user  interfaces  for  both  fast  retrievals 
and  updates  is  possible.  This  is  because  RAP's  proven  performance 
superiority  is  due  to  its  associative  selection,  set  oriented  processing, 
and  parallelism  features  [9].  As  a  result  of  these  features,  it  can  directly 
replace  many  record  and  set  processing  mechanisms  needed  in  conventional 
systems  for  mapping  the  user  level  to  the  storage  and  access  structure. 
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This  can  greatly  simplify  data  base  system  software  and  its  administration. 

Finally,  RAP  language  and  concept  is  general  enough  to  be  used 
even  without  an  underlying  data  base  machine.  Whenever  such  a  device 
becomes  available  it  can  easily  be  incorporated  for  superior 
performance  without  affecting  higher  levels  of  the  system. 
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Table-1:  Tabular  summary  of  RAP  instructions 


TYPE  OF  OPERATION 

INSTRUCTION 

TEMPLATE  TYPE 

EXECUTION  TIME  (REVOLUTIONS) 

Retrieval 

MARK 

General  (Restriction) 

1 

RESET 

General 

1 

READ 

General 

<3  revolutions  if  up  to 

5%  tuples  qualified. 

One  extra  revolution 
added  when  qualifica¬ 
tion  is  not  simple 

MKED(T)  (See  [9]  for 
detai Is.) 

READ_REG 

General 

Negligible 

CROSSJiARK 

0-Join,  Division, 
Restriction 

1  +  (#  source  marked 
tuples)/k  +  f#  of  source 
cells  with  marked  tuples) 

CRS_COND_MARK 

jO-Join,  Division, 
Restriction 

(cross  mark  time)  +  1 

GET_FIRST_MARK 

Projection,  Division, 
Restriction 

1  +  Fraction 

GET_FIRST 

General 

1 

SAVE 

General  (but  limited) 

1 

Update 

ADD 

DBMS  function 

1 

SUB 

DBMS  function 

1 

MUL 

DBMS  function 

1 

DIV 

DBMS  function 

1 

REPLACE 

DBMS  function 

1 

Set  function 
computati on 

COUNT 

DBMS  function 

1  +  Fraction 

MAX 

DBMS  function 

1  +  Fraction 

MIN 

DBMS  function 

1  +  Fraction 

SUM 

DBMS  function 

1  +  Fraction 

AVERAGE 

DBMS  function 

2  (maximum  3)  +  Fraction 
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Storage 

DELETE 

DBMS  function 

1 

INSERT 

DBMS  function 

Min=l,  Max=2  (See 
[2]  for  bulk  insertion) 

DR0P_D0MAIN 

DBMS  function 

Max  #  of  tuples/cell 
in  a  relation 

DESTROY 

DBMS  function 

Fraction 

CREATE 

DBMS  function 

1 

Decision  and 
transfer 

TEST 

General 

Negl igible 

BC 

General 

Megl igible 

EOQ 

General 

Negl igible 

ilote:  Execution 

time  is  given  in 

RAP  revolutions. 

Template  type  "General" 

means  can 

be  used  almost  in 

all.  "General  ( 

)"  means  although 

general  usage,  the  most  typical  is  in  the  parenthesis. 

"DBMS  function"  indicates  a  command  tailored  for  DBMS  operation  and  not 
essential  as  far  as  relational  algebra  is  concerned. 
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APPENDIX-1 

In  this  appendix  sample  programs  are  provided  for  illustrating  more 
general  versions  of  the  operations  described  in  the  text.  Cross  references 
from  the  main  text  are  given  to  the  exhibit  numbers  of  the  sample  programs. 
EXHIBIT-1:  UNION 

Two  relations  with  compatible  domains: 


R(D1 ,D2,D3,. . . ,D7) 

S(D1 ,D2,D3,. . . ,D7) 

The  RAP  program. 

MARK  (tl)  [R] 

LI  GET_FIRST  [R(D1 ,D2,D3) :MKED(tl )] 


MARK  (t2)  [S:D1  =  (REGCJ)  a  D2 

TEST  t2_RAIL 

BC  L2,  RAIL_STAT(t2) 

BC  RDTUPLE 

L2  MARK  (t3)  [R:UNMKED( tl t4) ] 


/*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

/*Read  into  RAP  registers  the  three 
domain  values  contained  in  the  first 
tl  marked  tuple*/ 

^  (REGCJ)  A  D3  =  (REGCJ)] 

/*Mark  all  tuples  of  relation  S  that 
have  the  same  three  domain  values*/ 
/*Any  match?*/ 

/*Yes*/ 

/*No*/ 

/*Three  of  the  domain  values  match. 
Check  if  the  next  three  match*/ 


/*Mark  current  R  tuple*/ 

GETJIRST  [R(D4,D5,D6)  :MKED(t3)]  /*Read  in  the  next  three  domain  values  of 

the  R  tuple*/ 

MARK  (t3)  [S:D4  =  (REGCJ)  a  D5  =  (REGCJ)  a  D6  =  (REGCJ)  a  MKED(t2)] 
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L3 


RESET  (t2)  [S] 
TEST  t3  RAIL 


BC  L3,RAIL_STAT( t3) 
BC  RDTUPLE 


/*t3  mark  those  satisfying  the  criteria  in  the 
tuples  previously  t2  marked  in  relation  S*/ 
/*Free  up  mark  bit  t2*/ 

/*Any  S  tuple  with  all  six  domain  values 
match?*/ 

/*Yes*/ 

/*No*/ 


/*Six  of  the  domain  values  match. 

Check  if  the  last  domain  matches*/ 
MARK  (t2)  [R: UNMKED( tl t4) ]  /*Mark  current  R  tuple*/ 

GET_FIRST  [R( D7) :MKED( t2) ]  /*Read  in  the  last  domain  value  of  the 

current  R  tuple*/ 

MARK  (t2)  [S:D7  =  (REGC-1)  a  MKED(t3)] 


RESET  (t3)  [S] 

TEST  t2_RAIL 

BC  SKIPl ,RAIL_STAT(t2) 

RDTUPLE  READ  [R:UNMKED( tl t4) ] [WORKAREA] 
BC  SKIP2 

SKIPl  RESET  (t2)  [S] 

SKIP2  MARK  (t4)  [R:UNMKED( tl t4)] 

TEST  tl_RAIL 

BC  LI ,RAIL  STAT(tl ) 


/*t2  mark  a  subset  of  the  previously 

t3  marked  tuples  of  relation  S  satisfying 
the  criteria*/ 

/*Free  up  mark  bit  t3*/ 

/*Any  S  tuple  with  all  domains  match?*/ 
/*Yes*/ 

/*No  tuple  in  relation  S  matches  the 
current  tuple  of  relation  R*/ 

/*0utput  the  unique  tuple*/ 

/*Housekeeping  before  we  can  proceed 
to  the  next  tuple  of  relation  R*/ 

/*Clear  work  mark  bit*/ 

/*Mark  current  R  tuple  as  processed*/ 

/*Any  more  R  tuples  to  be  processed?*/ 
/*Yes,  repeat  the  loop*/ 
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/*A11  tuples  of  relation  R  have  been 
processed.  Clean  up,  read  all  tuples 
of  relation  S,  and  exit*/ 

RESET  (t4)  [R] 

READ  [S][WORKAREA] 

EOQ 
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EXHIBIT-2:  INTERSECTION 
Relations  are  those  in  exhibit-1. 
The  RAP  program. 


MARK  (tl)  [R] 

/★Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

LI  GET  FIRST  [R(D1  ,02,03) :MKED(tl )] 


/*Read  into  REGCJ  ,2,3  the  three  domain 

values  contained  in  the  first  tl  marked 

tuple*/ 

MARK  (t2)  [S:01  =  (REGCJ)  a  02  = 

(REGCJ)  A  03  =  (REGCJ)] 

/*Mark  all  tuples  of  relation  S  that  has 

the  same  three  domain  values*/ 

TEST  t2_RAIL 

/*Any  such  tuple?*/ 

BC  L2,RAIL_STAT(t2) 

/*Yes*/ 

BC  SKIP 

/*No*/ 

/*Three  of  the  domains  match.  Check 

if  the  next  three  match*/ 

L2  MARK  (t3)  [R : UNMKE0( tl t4) ] 

/*Mark  current  R  tuple*/ 

GET_FIRST  [R(04,05,06):MKE0(t3)] 

/*Read  in  the  next  three  domain  values 

of  the  current  tuple*/ 

MARK  (t3)  [S;04  =  (REGCJ)  a  05  = 

(REGCJ)  A  06  =  (REGCJ)  a  MKE0(t2)] 

/*t3  mark  those  satisfying  the  criteria  in 

the  tuples  previously  t2  marked  in  relation 

S*/ 

RESET  (t2)  [S] 

/*Free  up  mark  bit  t2*/ 

TEST  t3_RAIL 

/*Any  S  tuple  with  all  six  domains  match?*/ 
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L3 


BC  L3,RAIL_STAT(t3) 
BC  SKIP 


MARK  (t2)  [R:UNMKED(tlt4)] 
GET_FIRST  [R(D7) ;MKED(t2)] 


/*Yes*/ 

/*No*/ 

/*Six  of  the  domains  match.  Check  if  the 
last  one  matches*/ 

/*Mark  current  R  tuple*/ 

/*Read  in  the  last  domain  value  of  the 
current  R  tuple*/ 


MARK  (t2)  [S:D7  =  (REGCJ)  a  MKED(t3)] 


RESET  (t3)  [S] 

TEST  t2_RAIL 
BC  RDTUPLE,RAIL_STAT(t2) 
BC  SKIP 


/*t2  mark  those  satisfying  the  criteria 
in  the  tuples  previously  t3  marked  in 
relation  S*/ 

/*Free  up  mark  bit  t3*/ 

/*Any  S  tuple  with  all  seven  domains  match?*/ 
/*Yes*/ 

/*No*/ 


/*There  is  a  tuple  in  relation  S  that  matches 
the  current  tuple  in  relation  R*/ 


RDTUPLE  READ  [R:UNMKED(tl t4)][W0RKAREA] 
RESET  (t2)  [S] 

SKIP  MARK  (t4)  [R:UNMKED(tlt4)] 

TEST  tl_RAIL 

BC  LI  ,RAIL_STAT(tl ) 

RESET  (t4)  [R] 

EOQ 


/*Clear  work  bits*/ 

/*Housekeeping  before  we  can  proceed  to 
the  next  tuple  of  relation*/ 

/*Mark  current  R  tuple  as  processed*/ 
/*Any  more  R  tuples  to  be  processed?*/ 
/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been 
processed.  Clean  up  and  exit*/ 
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EXHIBIT-3:  DIFFERENCE 

Assuming  the  same  relations  used  so  far,  the  following  RAP  program 


shows  the  difference  operation 

between  the  relations. 

MARK  (tl)  [R] 

/*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

GET_FIRST  [R(D1  ,D2,D3)  :MKED(tl )]  /*Read  into  REGCJ,2,3  the  three 

domain  values  contained  in  the  first  tl 
marked  tuple*/ 

MARK  (t2)  [S;D1  =  (REGCJ)  a  D2  =  (REGC_2)  a  D3  =  (REGC_3)] 


/*Mark  all  tuples  of  relation  S  that  have 

the  same  three  domain  values*/ 

TEST  t2JAIL 

/*Any  such  tuple?*/ 

BC  L2,RAILJTAT(t2) 

/*Yes*/ 

BC  RDTUPLE 

/*No*/ 

/*Three  of  the  domains  match. 

Check  if  the  next  three  match*/ 

MARK  (t3)  [R:UNMKED(tlt4)] 

/*Mark  current  R  tuple*/ 

GET_FIRST  [R(D4,D5,D6) :MKED(t3)]  /*Read  in  the  next  three  domain  values 

of  the  current  R  tuple*/ 

MARK  (t3)  [S;D4  =  (REGCJ)  a  D5  =  (REGCJ)  a  D6  =  (REGCJ)  a  MKED(t2)] 


RESET  (t2)  [S] 

/*t3  mark  those  satisfying  the  criteria  in  the 

previously  t2  marked  tuples  of  relation  S*/ 

/*Free  up  mark  bit  t2*/ 

TEST  tSJAIL 

/*Any  S  tuple  with  all  six  domains  match?*/ 

BC  L3,RAILJTAT(t3) 

/*Yes*/ 

BC  RDTUPLE 

/*No*/ 

/*Six  of  the  domains  match.  Check  if 

the  last  one  matches*/ 
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MARK  (t2)  [R:UNMKED(tlt4)] 
GET_FIRST  [R(D7) :MKED(t2)] 


/*Mark  current  R  tuple*/ 

/*Redd  in  the  last  domain  value  of  the 
current  R  tuple*/ 


MARK  (t2)  [S:D7  =  (REGCJ)  a  MKED(t3)] 


RESET  (t3)  [S] 

TEST  t2_RAIL 

BC  SKIPl ,RAIL_STAT(t2) 

RDTUPLE  READ  [R:UNMKED(tl t4)][W0RKAREA] 
BC  SKIP2 

SKIPl  RESET  (t2)  [S] 

SKIP2  MARK  (t4)  [R:UNMKED( tl t4) ] 

TEST  tl_RAIL 

BC  LI ,RAIL_STAT(tl) 

RESET  (t4)  [R] 

EOQ 

EXHIBIT-4:  RESTRICTION 


/*t2  mark  those  satisfying  the  criteria 
in  the  previously  t2  marked  tuples  of 
relation  S*/ 

/*Free  up  mark  bit  t2*/ 

/*Any  S  tuple  with  all  seven  domains  match?*/ 
/*Yes*/ 

/*No  tuple  in  relation  S  matches  the  current 
tuple  of  relation  R*/ 

/*Clear  work  mark  bits*/ 

/*Mark  current  R  tuple  as  processed*/ 

/*Any  more  R  tuples  to  be  processed?*/ 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been 
processed.  Clean  up  and  exit*/ 


. .DOl , . . . ,D07, . . . )  =  R(M, . . . ,N, . . . ) 


One  relation:  R(D1,...,D7, 

For  each  tuple  of  relation  R  check  if  the  relevant  domain  values  satisfy 
the  restriction  condition.  It  it  is  satisfied,  the  tuple  will  be  read  (or 
can  be  marked  with  a  different  mark  bit),  otherwise  it  will  be  ignored. 
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The  RAP  program. 

MARK  (tl)  [R]  /*Preprocess  for  loop*/ 

/*Loop  through  tuples  of  relation  R*/ 

LI  GET_FIRST  [R(D01 ,D02,D03) :MKED(tl )] 

/*Read  into  REGC_1,2,3  the  three 

domain  values  contained  in  the  first  tl 
marked  tuple*/ 

MARK  (t2)  [R;D1  0  (REGCJ)  a  D2  9  (REGC_2)  a  D3  6  (REGC_3)  a  L'NMKED(  tl  t4)  ] 

/*t2  mark  the  current  tuple  if  the 
three  pairs  of  values  satisfy  the 
restriction  condition.  (The  current 
tuple  is  the  only  tlt4  unmarked  tuple)*/ 

TEST  t2_RAIL  /*Condition  satisfied?*/ 

BC  L2,RAIL_STAT(t2)  /*Yes*/ 

BC  SKIP  /*No,  ignore  this  tuple*/ 

/*Three  pairs  of  domain  values  satisfy 
the  restriction  condition.  Check 
the  next  three  pairs*/ 

L2  GET_FIRST  [R(D04,D05,D06) ;MKED(t2)] 

/*Read  in  three  more  domain  values  from 
the  current  R  tuple  and  reset  its  t2 
mark  bit*/ 

MARK  (t2)  [R:D4  0  (REGCJ)  a  D5  0  (REGCJ)  a  D6  0  (REGCJ)  a  UNMKED( tl t4) ] 

/*t2  mark  the  current  tuple  again  if  these 
three  pairs  of  values  also  satisfy  the 
restriction  condition*/ 

TEST  t2  RAIL  /*Condition  satisfied?*/ 
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BC  L3,RAIL_STAT(t2) 

/*Yes*/ 

BC  SKIP 

/*No,  ignore  this  tuple*/ 

/*Six  pairs  of  domain  values  satisfy  the 

restriction  condition.  Check  the  last 
pai r*/ 


L3  GET_FIRST  [R(D07) :MKED( t2)] 

/*Read  in  the  last  domain  value  from  the 

current  tuple  and  reset  its  t2  mark 

bit*/ 

MARK  (t2)  [R:D7  e  (REGCJ)  a  UNMKED( tl t4) ] 


TEST  t2_RAIL 

/*t2  mark  the  tuple  again  if  the 

restriction  condition  is  satisfied*/ 

/*Condition  satisfied?*/ 

BC  L4,RAIL_STAT(t2) 

/*Yes*/ 

BC  SKIP 

/*No,  ignore  this  tuple*/ 

/*The  current  tuple  satisfies  the 

restriction  condition,  read  it  out*/ 

L4  READ  [R:MKED(t2)][W0RKAREA] 


SKIP  MARK  (t4)  [R:UNMKED(tlt4)] 

/*Housekeeping  before  we  can  proceed  to 

the  next  tuple  of  relation  R*/ 

/*Mark  tuple  as  processed*/ 

TEST  tl_RAIL 

/*Any  more  tuples  to  be  processed?*/ 

BC  LI ,RAIL_STAT(tl) 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  have  been  processed. 

RESET  (t4)  [R] 
EOQ 


Clean  up  and  exit*/ 
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EXHIBIT-5:  PROJECTION 

Assume  relation  R(D1 , . . . ,07 , . . . )  =  R(M,...)  where  M  is  list  of  domain 
names . 

The  RAP  program. 

First  tl  mark  all  tuples  of  relation  R.  Then,  starting  from  the  first 
tl  marked  tuple,  compare  values  of  the  domains  to  be  projected  with  those 
of  all  other  tl  marked  tuples.  The  first  tl  marked  tuple  is  then  read 
and  also  tl  unmarked  so  that  next  tl  marked  tuple  becomes  the  next  first. 
Those  with  matching  values  are  also  tl  unmarked  so  that  they  should  not 


be  processed  again.  Repeat  till 

all  tuples  are  tl  unmarked. 

MARK  (tl)  [R] 

/*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation  R*/ 

LI  GET_FIRST_MARK  (t2)  [R( 02 ,03 ,04) : 01  =  01 ][MKE0(tl ) ] 


/*Read  into  REGC  1,2,3  the  three  domain 

values  contained  in  the  first  tl  marked 

tuple  and  t2  mark  all  tuples  with  matching 

01  value*/ 

TEST  t2_RAIL 

/*Any  such  tuple?*/ 

BC  L2,RAIL_STAT(t2) 

/*Yes*/ 

BC  ROTUPLE 

/*No  duplicate*/ 

/*0ne  of  the  domain  values  matches.  Check 

if  the  next  three  match*/ 

L2  ’  MARK  (t3)  [R:02  =  (REGCJ)  a  03  = 

=  (REGCJ)  A  04  =  (REGCJ)  a  MKE0(t2)] 

/*t3  mark  tuples  with  all  four  domains  match*/ 

RESET  (t2)  [R] 

/*Free  up  mark  bit*/ 

TEST  t3_RAIL 

/*Any  such  tuple?*/ 

BC  L3,RAIL_STAT(t3) 

BC  ROTUPLE 

/*Yes*/ 

/*No  duplicate*/ 

BC  ROTUPLE 
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L3  MARK  (t2)  [R:UNMKED(tlt4)] 

GET_FIRST  [R(D5,D6,D7) :MKED(t2)] 
MARK  (t2)  [R:D5  =  (REGCJ)  a  D6 
RESET  (t3)  [R] 

TEST  t2_RAIL 
BC  L4,RAIL_STAT(t2) 

BC  RDTUPLE 

L4  MARK  (t4)  [R:MKED( tlt2)] 

RESET.  (tlt2)  [R] 


RDTUPLE  READ  [R: UNMKED( tl t4) ] [WORKAREA] 
MARK  {t4)  [R:UNMKED(tlt4)] 

TEST  tl_RAIL 

BC  LI ,RAIL_STAT(tl ) 

RESET  (t4)  [R] 

EOQ 

EXHIBIT-6: 

Two  relations: 


/*Four  of  the  domains  match. 

Check  if  the  last  three  match*/ 

/*Mark  the  current  tuple*/ 

/*Get  its  other  domain  values*/ 

(REGC_2)  A  D7  =  (REGC_3)  a  MKED(t3)] 
/*Free  up  mark  bit*/ 

/*Any  tuple  with  seven  domains  match?*/ 
/*Yes*/ 

/*No  duplicate*/ 

/*A11  duplicates  have  been  t2  marked*/ 

/*t4  mark  the  duplicates*/ 

/*Clear  the  bits  so  that  tuples  will 
not  be  picked  up  again*/ 

/*Dupl i cates ,  if  any,  have  been  t4  marked 
and  tl  unmarked.  Read  the  current 
R  tuples  (only  the  domains  projected, 
the  rest  of  the  tuple  is  not  read  out)*/ 

/*Mark  tuple  as  processed*/ 

/*Any  more  tuples  to  be  processed?*/ 

/*Yes,  repeat  the  loop*/ 

/*A11  tuples  have  been  processed. 

Clean  up  and  exit*/ 


DIVISION  (General  case) 

R(D1,D2,...,D7,D01,D02,...,D08) 
S(D1 ,D2,. . . ,D8,. . .) 
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L  represents  the  list  of  domain  names  (D1 ,D2 . ,D7) 

M  represents  the  list  of  domain  names  (DOl ,D02 , . . . ,D08) 

N  represents  the  list  of  domain  names  (D1 ,D2 . ,D8) 

So  that  the  relations  can  be  represented  as: 

R(L,M)  and  S(N,...) 

Algebra:  R[MtN]S  or  R[L,M]/S[N] 

Calculus:  (r[M]:r6R  a  (y :  (r[M]  ,y)£R)  d_  S[N])  where  M  =  L 
The  RAP  program. 

This  is  an  extension  of  the  second  division  example  given  in  the  main  text. 
(First,  project  on  domains  D1,D2,...,D8  of  the  divisor  and  t5  mark  the 
unique  tuples.  Also  reset  all  other  used  mark  bits.  The  code  for  doing 
these  is  similar  to  the  RAP  program  presented  in  the  previous  exhibit  for 
projecti on . ) 

COUNT  [S:MKED(t5)]  /*Count  no.  of  t5  marked  divisor  tuples*/ 

MARK  (tl)  [R]  /*Preprocess  for  loop*/ 

/*Loop  thru  tuples  of  relation*/ 

LO  GET_FIRST_MARK  (t3)  [R( D2 ,D3 ,D4) : D1  =  D1 ][MKED(tl )] 

/*Read  into  REGC_1,2,3  the  three  domain 
values  contained  in  the  first  tl  marked 
tuple  and  group  the  relation  on  the  basis 
of  these  values*/ 

TEST  t3_RAIL  /*Any  such  tuple?*/ 

BC  LI ,RAIL_STAT(t3)  /*Yes*/ 

BC  LLO  /*No  duplicate*/ 

/*0ne  of  the  domains  matches.  Check  if 
the  next  three  match*/ 

LI  MARK  (t4)  [R:D2  =  (REGCJ)  a  D3  =  (REGC_2)  a  D4  =  (REGC_3)  a  MKED(t3)] 

RESET  (t3)  [R]  /*Free  up  mark  bit  t3*/ 
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TEST  t4_RAIL 
BC  L2,RAIL_STAT(t4) 


BC  LLO 

/*No  duplicate*/ 

/*Four  of  the  domain  values  match.  Check 

if  the  next  three  match*/ 

L2  MARK  (t3)  [R:UNMKED(tlt2)]  /*Mark  the  current  tuple*/ 

GET_FIRST  [R(D5,D6,D7):MKED(t3)] 


MARK  (t3)  [R:D5  =  (REGCJ)  a  D6 

=  (REGCJ)  A  07  =  (REGCJ)  a  MKED(t4)] 

RESET  (t4)  [R] 

/*A11  duplicates  (if  any)  have  been  t3 

marked*/ 

LLO  MARK  (t3)  [R:UNMKED(tl t2)] 

/*t3  mark  the  current  tuple*/ 

COUNT  [R:MKED(t3)][2] 

BC  SKIP1,(REGFJ)  >  (REGF_2 

/*If  no.  of  t5  marked  tuples  is  greater 

than  the  no.  of  t3  marked  tuples,  skip 

since  it  will  fail*/ 

/*Check  all  t5  marked  tuples  of  relation 

S  against  all  t3  marked  tuples  of 

relation  R.  If  a  match  is  found  for 

all  the  t5  marked  tuples  the  current 

tuple  of  relation  R  will  be  read  out*/ 

MARK  (t4)  [S:MKED(t5)] 

MARK  (t6)  [S:UNMKED(t5)] 

/*For  remembering  the  current  tuple 

of  relation  S  --  it  will  be  t4t6 

marked*/ 

/*Loop  thru  all  t5  marked  tuples  of 

relation  S  (now  also  t4  marked)*/ 

( 

LLl  GET_FIRST  [S(D1  ,D2 ,D3) :MKED( t4)]  /*Read  in  the  three  domain  values  of 


the  first  t4  marked  tuple*/ 
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MARK  (t7)  [R:D01  =  (REGCJ)  a  D02  =  (REGCJ)  a  DOS  =  (REGC_3)  a  MKED(t3)] 


TEST  t7JAIL 

/*Group  R  according  to  these  values*/ 

/*Any  such  tuple?*/ 

BC  LL2,RAILJTAT(t7) 

/*Yes*/ 

BC  SKIP 

/*No*/ 

/*Three  of  the  domains  match.  Check 

if  the  next  three  match*/ 

LL2  MARK  (t8)  [S:UNMKED(t4t6)] 

/*Mark  the  current  S  tuple*/ 

GET_FIRST  [S(D4,D5,D6) :MKED(t8)] 

MARK  (t8)  [R:D04  =  (REGCJ)  a  005  =  (REGCJ)  a  D06  =  (REGCJ)  a  MKED(t7)] 


RESET  (t7)  [R] 

/*Free  up  mark  bit*/ 

TEST  t8JAIL 

/*Any  R  tuple  with  all  six  domains  match?*/ 

BC  LL3,RAILJTAT(t8) 

/*Yes*/ 

BC  SKIP 

/*No*/ 

/*Six  of  the  domains  match.  Check  if 

the  next  two  match*/ 

LL3  MARK  (t7)  [S:UNMKED(t4t6)] 

/*Mark  the  current  S  tuple*/ 

GETJIRST  [D(D7,D8):MKED(t7)] 

MARK  (t7)  [R;D07  «  (REGCJ)  a  D08  =  (REGCJ)  a  MKED(t8)] 


RESET  (t8)  [R] 

/*Free  up  mark  bit  t8*/ 

TEST  t7JAIL 

/*Any  R  tuple  with  all  eight  domains 

match?*/ 

BC  LL4,RAILJTAT(t7) 

/*Yes*/ 

BC  SKIP 

/*No*/ 

/*We  have  found  a  match  for  the  current 

tuple  of  the  divisor.  Now  repeat 

for  the  next  t5  marked  tuple  which  is 

also  the  first  t4  marked  tuple*/ 
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LL4  RESET  (t7)  [R] 

MARK  (t6)  [S:UNMKED(t4t6)] 

TEST  t4_RAIL 

BC  LLl ,RAIL_STAT(t4) 


READ  [R:UNMKED(tU2)][W0RKAREA] 

SKIP  RESET  (t4t6)  [S] 


SKIPl  MARK  (t2)  [R:MKED(t3)] 
RESET  (tits)  [R] 

TEST  tl_RAIL 
BC  LO,RAIL_STAT(tl) 

RESET  (t2)  [R] 

RESET  (t5)  [S] 

EOQ 


/*Cledr  the  work  mark  bit*/ 

/*t6  mark  the  current  tuple  before  we 
proceed  to  the  next  one*/ 

/*Any  more  S  tuples?*/ 

/*Yes,  repeat  the  loop*/ 

/*We  have  found  a  match  for  all  the 
t5  marked  tuples  of  the  divisor.  So 
read  out  the  current  tuple  of  the 
dividend.  (Note;  only  the  values 
for  domains  D1 ,D2 ,D3 , . . . ,D7  are 
relevant.  The  rest  of  the  tuple  is 
not  read*/ 

/*Housekeeping  before  we  can  proceed 
to  the  next  tuple  of  the  dividend*/ 
/*Clear  marks  t4t6.  Some  S  tuples 
might  still  be  t4  marked  if  this 
instruction  is  reached  as  a  result 
of  a  branch  instruction*/ 

/*t2  mark  the  R  tuple  just  processed*/ 
/*Clear  work  bits*/ 

/*Any  more  R  tuples  to  be  processed?*/ 
/*Yes,  repeat  the  loop*/ 

/*A11  tuples  of  relation  R  have  been 
processed.  Clean  up  and  exit*/ 
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APPENDIX-2 


As  pointed  out  in  respective  places  of  the  RAP  architectural 
description  there  are  several  modular  features  in  the  design.  The 
parameters  that  characterize  these  features  are  variable  and  choice 
of  specific  values  for  them  is  controlled  by  several  factors  such  as  cost, 
space,  hardware  feasibility,  and  software  requirement.  The  table  below 
summarizes  the  values  assumed  for  these  parameters  which  are  presently 
implemented  and/or  modelled. 


PARAMETERS 


Buffer  length 


Degree  of  a  RAP 
relation 


m 


Item  lengths 


DESCRIPTION 


Length  of  the  shi ft 
register  buffer  between 
memory  read  and  write 
mechanisms . 

Number  of  items  (or 
attribute  values)  that 
can  be  stored  in  a  RAP 
tuple. 

Number  of  mark  bits 
per  tuple 

Length  of  a  domain  value 
i  tern 


PRESENT  VALUE 
1024  bits 


>  29 
<101 


8 


8,  16,  or  32  bits 


RAP  tuple  lengths 


Gap3  length 


s 


k 


Lengths  that  a  RAP  tuple 
can  assume 


Length  of  memory  gap 
between  tuples 


Specification  list 
length.  That  is,  the 
number  of  domain  names 
in  a  specification  list 


Variable  between  the 
bounds  of  256  and 
1024.  Lower  bound 
is  minimum  if  multip¬ 
lication  is  implemented. 

Variable  and  depends 
upon  the  exact  length 
of  the  tuple 

3 


Number  of  comparator  units  5 
(i.e.,  qualification  compa¬ 
rator  units)  per  cell 
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PARAMETERS 

DESCRIPTION 

PRESENT  VALUE 

r 

Number  of  items  that 

can  be  saved  in  a  get_first 

type  command. 

3 

Number  of  REGC 
registers 

Number  of  REGC  controller 
registers  which  are  used  in 
saving  item  values. 

r 

Bit  time 

Time  between  two  bit  pulses 
(therefore  bit  frequency) 

100  ns  (10  MHz) 

Cell  memory  capacity 

Total  number  of  bits  per  cell 

0.5*10^  bits 
(anticipated) 

Memory  rotational 
delay  or  circulation  time 

RAP  memory  revolution  time 

50  ms  (dependent 
upon  bit  time 
and  memory 
capacity) 
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APPENDIX-3 

In  this  appendix  we  include  some  programming  examples  in  the 
RAP  assembler  language.  These  examples  demonstrate  the  use  of  RAP's 
data  sublanguage  at  the  machine  level.  Also,  in  some  examples  the 
ideas  presented  with  the  relational  templates  are  utilized.  References 
to  these  queries  are  given  in  the  templates.  In  particular,  we  felt 
that  use  of  the  data  base  and  selected  queries  used  in  the  description 
of  the  SQUARE  language  [7]  would  be  useful.  In  this  way,  the  features 
of  the  RAP  language  can  be  understood  easier  and  consistency  with  the 
concepts  documented  elsewhere  [1  through  4]  can  be  maintained.  In  the 
following  the  data  base  used  in  the  examples  is  described  in  the  usual 
notation,  i.e.,  relation  name  followed  by  domain  names  (attributes)  in 
parentheses. 

E  MP ( NAME , SAL , MGR , DE  PT , COMM ) 

LOCATION (DEPT, FLOOR) 

SALES(DEPT, ITEM, VOL) 

SUPPLY(COMPANY, ITEM, DEPT, VOL) 

CLASS(ITEM,TYPE) 

NEWSALES(DEPT, ITEM, VOL) 

where  abbreviations  EMP,  SAL,  COMM,  and  VOL  stand  for  employee,  salary, 
commission,  and  volume  respectively.  The  employee  relation  has  a  tuple 
for  every  employee  giving  his  name,  department,  manager's  name,  salary, 
and  commission.  The  location  relation  gives  the  floor  on  which  each 
department  is  located,  that  is,  it  has  a  tuple  for  each  department  floor 
pair.  The  sales  relation  has  a  tuple  indicating  the  yearly  volume  sold 
for  an  item  in  each  department.  The  relation  class  has  tuples  giving 
a  specific  type  of  an  item  sold  in  the  departments.  The  newsales 
relation  is  a  relation  similar  to  sales,  it  relates  current  sales  data 
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that  has  not  yet  been  accummulated  into  the  sales  relation.  The  supply 
relation  indicates  suppliers  supplying  departments  according  to  a  specific 
item  and  gives  the  volume  supplied. 

The  example  queries. 

Q1 .  Find  the  employee  whose  whose  salary  is  greater  than  that  of  any 
employee  in  the  SHOE  department. 

The  RAP  program. 

MAX  [EMP(SAL):DEPT  =  'SHOE'] 

MARK  (tl)  [EMPrSAL  >  (REGFJ)] 

EOQ 

This  program  demonstrates  the  in-place  set  function  (i.e.  statistical 
function)  computation  capability  of  RAP.  Also,  the  mark  instruction 
shows  the  restriction  operation,  by  tl  marking,  on  those  employee  tuples 
whose  salary  is  greater  than  the  criterion  --  that  is,  the  computed  result 
of  the  set  function  operation  of  maximum. 

Q2.  List  the  names  and  managers  of  employees  in  the  SHOE  department 
with  salaries  greater  than  10,000. 

The  RAP  program. 

READ  [EMP(NAME,MGR):(DEPT  =  'SHOE')  a  (SAL  >  10000)][W0RKAREA] 

EOQ 

In  here,  we  see  the  powerful  read  instruction  which  executes  a  Boolean 
selection  on  the  employee  tuples  and  transfers  name  and  manager  of  the 
qualified  tuples  to  the  supporting  processor. 

Q3.  Move  the  location  of  the  TOY  department  to  the  second  floor. 

The  RAP  program. 

REPLACE  [L0C( FLOOR): DEPT  =  'T0Y'][2] 

EOQ 
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As  in  the  previous  instruction,  we  see  the  powerful  RAP  selection  (not 
necessarily  the  strict  definition  of  the  term  as  used  in  relational 
algebra)  as  part  of  an  instruction.  The  above  single  instruction  RAP 
program  (excluding  the  last  statement)  shows  RAP's  in-place  selection  and 
update  capability. 

Q4.  Delete  from  employee  relation  all  the  employees  who  work  for 
ANDERSON'S  manager. 

The  RAP  program. 

SAVE  [EMP ( MGR) : NAME  =  'ANDERSON'] 

DELETE  [EMPiMGR  =  (REGS)] 

EOQ 

The  save  instruction  can  be  used  if  it  is  known,  semantically,  that  a 
single  tuple  will  be  qualified  in  the  data  base.  This  way,  program  looping 
would  be  avoided.  The  delete  instruction  takes  one  revolution  to  execute. 
It  may  be  followed  by  automatic  hardware  garbage  collection  whenever  the 
relation  is  not  referenced. 

Q5.  Add  the  contents  of  the  variable  SOLD  to  the  volume  for  the  item 
SLIPPERS  in  the  SHOE  department. 

The  RAP  program. 

ADD  [SALES( VOL) :( DEPT  =  'SHOE')  a  (ITEM  =  'SLIPPERS ' )][(S0LD)] 

EOQ 

Q6.  Add  commission  of  the  salesman  CLARK  in  the  SHOE  department  to 
his  salary. 

The  RAP  program. 

ADD  (tl)  [EMP(SAL,COMM):(DEPT  =  'SHOE')  a  (NAME  =  'CLARK' )][C0MM] 

EOQ 

In  both  of  the  arithmetic  update  queries  of  Q5  and  Q6  above,  we  see  the 
in-place  Boolean  selection  and  update  capability  of  RAP.  In  Q6  it 
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is  shown  that  both  operands  of  an  arithmetic  update  can  be  domains. 
Further,  Q6  demonstrates  the  use  of  marking  option  during  updates. 

This  capability  provides  ease  of  recovery  in  case  of  device 
failures. 

Q7.  Delete  all  tuples  of  the  data  base  relation  newsales  involving 
employee  CLARK'S  department  and  the  item  SLIPPERS. 

The  RAP  program. 

SAVE  [EMP(DEPT) :NAME  =  'CLARK'] 

/*Save  CLARK'S  department*/ 

MARK  (tl)  [NEWSALES: DEPT  =  (REGS)] 

/*Mark  this  department  in  newsales*/ 
RESET  (tl)  [NEWSALES: (MKED(tl))  a  (ITEM/  'SLIPPERS')] 

/*Reset  mark  bits  if  qualifiers  are 
not  in  combination*/ 

DELETE  [NEWSALES:MKED(tl )]  /*Delete  tuples  in  which  both  qualifiers 

exist*/ 

EOQ 

In  this  program  we  can  see  the  power  of  a  reset  instruction  driven  by 
a  Boolean  qualification. 

Q8.  Find  the  total  volume  of  items  of  type  A  sold  by  the  departments 
on  the  second  floor. 

The  RAP  program. 

MARK  (tl)  [LOC: FLOOR  =  2]  /*Mark  second  floor  tuples*/ 

CROSS_MARK  (t2)  [SALES: DEPT  =  LOC. DEPT] [LOC. MKED( tl )] 

/*Mark  sales  tuples  with  departments 
on  the  second  floor*/ 

MARK  (tl)  [CLASS :TYPE  =  'A']  /*Mark  'A'  type  items*/ 

CRS_COND_MARK  (t2[t3])  [SALES:ITEM  =  CLASS. ITEM] [CLASS. MKED( tl )] 
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/*Retain  t2  marked  sales  tuples  if  their 
items  are  of  'A'  type,  otherwise  reset*/ 
SUM  [SALES ( VOL ) :MKED(t2)]  /*Find  the  total  volume  of  items  of  type 

'A'  sold  by  departments  on  the  second 
floor*/ 

READ_REG  [(REGFJ)]  /*0utput  the  result*/ 

RESET  (t2)  [SALES]  /*Clear  mark  bit*/ 

EOQ 

In  this  program  we  have  seen  cross_mark  type  of  mapping  or  implicit  join 
operations  (i.e.,  crossjnark  and  crs_cond_mark) .  The  iteration  in  them  is 
implicit  in  hardware  during  their  operations.  The  operations  come  to 
end  whenever  all  of  the  source  relation  markings  used  as  qualifier  are 
reset. 

Q9.  Find  the  names  of  employees  who  earn  more  than  their  managers. 

The  RAP  program. 

MARK  (tl)  [EMP]  /*Preprocess  before  loop*/ 

LI  GET_FIRST  [EMP(MGR,SAL) :MKED( tl ) ] 

/*Check  the  first  tl  marked  employee 
tuple.  Save  his  salary  and  manager's 
name  in  REGC_1 ,2*/ 

SAVE  [EMP ( SAL ): NAME  =  (REGC_1)]  /*Find  his  manager,  and  save  his  salary*/ 
BC  L2,(REGC_2)  <  (REGS)  /*Compare  salaries*/ 

READ  [EMP (NAME , MGR) : UNMKED( tl t2 ) ] [WORKAREA] 

/*Employee  earns  more  than  the  manager. 
Read  out  employee's  and  his  manager's 
names*/ 

L2  MARK  (t2)  [EMP:UNMKED(tlt2)]  /*Mark  off  processed  tuples*/ 

TEST  tl_RAIL  /*Any  more  employee  tuples?*/ 

BC  LI ,RAIL_STAT(tl )  /*Yes,  repeat  the  loop*/ 
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L1 


L2 


RESET  {t2)  [EMP]  /*Clear  and  exit*/ 

EOQ 

The  above  program  shows  how  explicit  program  looping  is  constructed  for 
doing  free  variable  type  processing  where  values  of  tuples  within  a  relation 
are  correlated.  The  feature  of  get_first  type  instructions  enables 
programming  of  sequential  oriented  processes  in  RAP.  Below,  two  more 
examples  will  follow  which  implement  grouping  operation  with  the  basic 
constructs  of  free  variable  processing. 

QIO.  Find  the  names  of  managers  who  manage  more  than  ten  employees. 

The  RAP  program. 


MARK  (t4)  [EMP]  /*Preprocess  for  loop*/ 

GET_FIRST_MARK  (t2)  [EMP: MGR  =  MGR][MKED(t4)] 


/*t2  mark  those  employees  with  the  same 
manager*/ 

COUNT  [EMP :MKED(t2)]  /*Count  employees  with  the  same  manager*/ 

BC  L2,{REGF_1)  <  10  /*Skip  if  not  more  than  10  employees*/ 

READ  [EMP(MGR) :UNMKED(t3t4)][W0RKAREA] 


RESET  (t2t4)  [EMP:MKED(t2)] 
MARK  (t3)  [EMP:UNMKED(t3t4)] 
TEST  t4_RAIL 
BC  LI ,RAIL_STAT(t4) 

RESET  (t3)  [EMP] 

EOQ 


/*Read  the  manager's  name*/ 
/*Clear  mark  bits*/ 

/*Mark  off  the  processed  tuple*/ 
/*A11  managers  are  looked  at?*/ 
/*No,  repeat  the  loop*/ 

/*Clear  and  exit*/ 


The  get_first_mark  instruction  enables  grouping  by  its  self-marking 
feature.  In  this  instruction  any  two  domains  of  the  relation  can  be 
compared,  however  in  most  of  the  examples  studied,  it  turns  out  that 
mostly  same  domain  plays  the  part  of  both  operands  due  to  semantic 
feature  of  the  self-looped  structures. 
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L1 


L2 


L3 


C 

Qll.  Among  all  departments  with  total  salary  greater  than  $10  find  those 
departments  which  sell  dresses. 

The  RAP  program. 

MARK  (tlt2)  [EMP]  /*Preprocess  for  projection*/ 

GET_FIRST_MARK  (t3)  [EMPrDEPT  =  DEPT][MKED(t2)] 

/*Mark  duplicates*/ 

RESET  (tlt2t3)  [EMP]  /*Mark  off  duplicates*/ 

TEST  t2_RAIL  /*Any  more  values?*/ 

BC  LI ,RAIL_STAT(t2)  /*Yes,  so  repeat  the  loop*/ 

GET_FIRST  [EMP(DEPT):MKED(tl)]  /*Pick  the  first  unique  department*/ 

SUM  [EMP(SAL) :DEPT  =  (REGC_1)]  /*Sum  the  salaries  within  the  department*/ 

BC  L3,((REGF_1)  <  1000000)  /*Skip  if  total  salary  is  not  greater*/ 

MARK  (t2)  [SALES:  (DEPT  =  (REGCJ))  a  (ITEM  =  'DRESSES')] 

/*Mark  the  department  with  total  salary  > 

C 

10  and  selling  dresses*/ 

TEST  tl_RAIL  /*Are  all  departments  looked  at?*/ 

BC  L2 ,RAIL_STAT(tl )  /*No,  go  and  repeat  the  loop*/ 

READ  [SALES(DEPT) :MKED(t2)][W0RKAREA] 

/*Read  out  eligible  departments*/ 


EOQ 

Again,  in  this  program  we  see  the  use  of  program  iteration  by  the  use 
of  get_first  type  instructions.  The  first  loop  was  to  project  department 
values  so  that  duplications  could  be  avoided.  Since  projection  in  RAP 
is  accomplished  implicitly  by  marking,  the  projected  values  can  still  be 
used  with  any  desired  domain  in  the  original  relation.  The  second  loop 
does  the  grouping  by  examining  each  unique  department  and  grouping  those, 
with  the  mark  instruction,  that  satisfy  the  criteria. 

Q12.  Find  companies  each  of  which  supplies  every  item  of  type  A  to 
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some  department  on  the  second  floor. 

Note  that  this  query  is  taken  from  the  SQUARE  language  paper  and  the 
same  data  base  is  used. 

The  RAP  program. 

MARK  (tl)  [LOG: FLOOR  =  2] 

CROSS_MARK  (t2)  [SUPPLY: DEPT  =  LOG. DEPT] [LOG. MKED( tl )] 

/*Mark  supply  tuples  that  indicate 
companies  supplying  departments  on 
the  second  floor*/ 

MARK  (tl)  [GLASS:TYPE  =  'A'] 

(RAP  code  to  project  tl  marked  class  tuples.  Gode  is  not  included  here. 
Unique  tuples  are  t3  marked  at  the  end  of  the  projection) 

GOUNT  [GLASS :MKED(t3)]  /*Gount  no.  of  A  type  items*/ 

MARK  (t4)  [GLASS:MKED(t3)]  /*Gopy  mark  bits  onto  another  mark  domain*/ 

(RAP  code--not  included  here--to  project  supply  tuples  on  company. 

Unique  tuples  are  t5  marked.)  /*Division  operation  into  the  class  relation 

with  each  company  being  the  divisor 
follows*/ 

LI  GET_FIRST  [SUPPLY(GOMPANY) :MKED(t5)] 

/*Get  company  at  a  time*/ 

MARK  (tl)  [SUPPLY :G0MPANY  =  (REGGJ)] 

/*Mark  only  that  company's  tuples*/ 
GRS_GOND_MARK  (t3[t6])  [GLASS: ITEM  =  SUPPLY. ITEM] [SUPPLY. MKED(tl )] 

GOUNT  [GLASS:MKED(t3)][2] 

BG  L2,(REGFJ)  f  (REGF_2) 

READ_REG  [(REGG_1)]  /*Read  out  the  company  if  it  satisfies 

the  division  i.e.,  it  supplies  every 
item  of  type  A  sold  to  departments  on 
the  second  floor*/ 
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L2  RESET  (t3)  [CLASS] 

MARK  (t3)  [CLASS :MKED(t4)] 

TEST  t5_RAIL 

BC  LI ,RAIL_STAT(t5) 

RESET  (t3t4)  [CLASS] 

EOQ 


/*Clear  work  mark  bits*/ 

/*Refresh  mark  bits  by  recopying  from 
t4*/ 

/*Are  all  companies  processed?*/ 

/*No,  repeat  the  loop*/ 

/*Clean  up  and  exit*/ 
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